You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by William McKee <wi...@knowmad.com> on 2004/03/10 23:01:34 UTC
Failures in TestRun.pm with A::T 1.09
Hi Stas,
I recently upgraded my workstation for A::T 1.07 to 1.09. Immediately
upon doing so, I started to receive test failures. It turns out that
these failures were due to lines 613 and 1573 of Apache::TestRun. The
error was actually a warning as follows:
Statement unlikely to be reached at
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux/Apache/TestRun.pm line
613.
However, following the examples I've seen for TEST.PL, I had the
following line in my TEST script:
use warnings FATAL => 'all';
This caused the tests to fail. I tried reinstalling Apache::Test 1.07
and 1.08 but neither made any difference. I don't know why this started
showing up in 1.09, but it seems like it should be removed. I've
attached a diff that comments out these lines.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Wed, Mar 10, 2004 at 05:01:34PM -0500, William McKee wrote:
> This caused the tests to fail. I tried reinstalling Apache::Test 1.07
> and 1.08 but neither made any difference. I don't know why this started
> showing up in 1.09, but it seems like it should be removed. I've
> attached a diff that comments out these lines.
Oops, please run a reverse diff if you plan on applying that patch. I'm
still a newbie with diff ;).
-Wm
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Fri, Mar 12, 2004 at 11:17:50PM -0500, William McKee wrote:
>
>>Just FYI, after moving the libperl.* out of /usr/lib and rebuilding
>>Apache/mp, I'm still having problems with the TestRun.pm module. I'll
>>try building Perl with O2 next.
>
>
> Rebuilt Perl and mod_perl with -O2. But I'm still getting the same
> "Statement unlikely to be reached" error message around line 636. I'm
> going to have to chalk it up to environmental problems for now and move
> on. Perhaps when I rebuild my Perl setup here, I can do further testing.
Thanks for trying all these, William.
Now please give us something we can reproduce the problem with. i.e. a tar
with a complete setup (and as little code as possible) and we will look at it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Fri, Mar 12, 2004 at 11:17:50PM -0500, William McKee wrote:
> Just FYI, after moving the libperl.* out of /usr/lib and rebuilding
> Apache/mp, I'm still having problems with the TestRun.pm module. I'll
> try building Perl with O2 next.
Rebuilt Perl and mod_perl with -O2. But I'm still getting the same
"Statement unlikely to be reached" error message around line 636. I'm
going to have to chalk it up to environmental problems for now and move
on. Perhaps when I rebuild my Perl setup here, I can do further testing.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Mon, Mar 15, 2004 at 01:30:51PM -0800, Stas Bekman wrote:
> Have you been talking about mod_perl 1 all this time?
Yep.
> If not, you can only build mp2 as DSO at the moment. You don't need to
> build perl with -Duseshrplib to get a DSO mod_perl build (certainly
> for mp2, not 100% sure about mp1).
OK, that's good to know. I had some build troubles several months back
and must have come across some suggestions to use that option and found
it to work. I prob. forgot a step initially which I did not forget when
using the -Duseshrplib. At any rate, I've found that I don't need that
option anymore which simplifies my build process.
Cheers!
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Fri, Mar 12, 2004 at 07:44:46PM -0800, Stas Bekman wrote:
>
>>that's when you start apache/mp, right? You need to remove that library and
>>then rebuild mod_perl. It should now find the library under
>>/usr/local/lib/perl5/.../libperl.so
>
>
> Yeah, sure enough I moved all the libperl.so.* out of the /usr/lib/ path
> and recompiled apache/mp. It worked fine. I don't know why I had it
> stuck in my build process that I needed to create these links. So do I
> really even need to compile Perl with -Duseshrplib? It seems like
> mod_perl requires this library (although I'm not building it as a DSO, I
> have DSO enabled and am using APACI).
Have you been talking about mod_perl 1 all this time? If not, you can only
build mp2 as DSO at the moment. You don't need to build perl with -Duseshrplib
to get a DSO mod_perl build (certainly for mp2, not 100% sure about mp1).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Fri, Mar 12, 2004 at 07:44:46PM -0800, Stas Bekman wrote:
> that's when you start apache/mp, right? You need to remove that library and
> then rebuild mod_perl. It should now find the library under
> /usr/local/lib/perl5/.../libperl.so
Yeah, sure enough I moved all the libperl.so.* out of the /usr/lib/ path
and recompiled apache/mp. It worked fine. I don't know why I had it
stuck in my build process that I needed to create these links. So do I
really even need to compile Perl with -Duseshrplib? It seems like
mod_perl requires this library (although I'm not building it as a DSO, I
have DSO enabled and am using APACI).
> >Yeah, that's certainly a concern. I'd like to figure out my
> >misconfiguration issue above then will attempt your proposal to nuke all
> >these old installations and start fresh.
>
> at least move them into some safe location (like some foo dir under your
> home directory).
Just FYI, after moving the libperl.* out of /usr/lib and rebuilding
Apache/mp, I'm still having problems with the TestRun.pm module. I'll
try building Perl with O2 next.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Mon, Mar 15, 2004 at 01:33:25PM -0800, Stas Bekman wrote:
> Neither to me. Are you sure you get the "Statement unlikely to be reached"
> error from the same place? It happens long before the server has started,
> and "failed to resolve handler" is an error from the run-time or a server
> startup.
> Again, giving us a tar to play with should be helpful.
Yes, they are happening at line 636 which is the die statement in the
set_ulimit_via_sh sub. I agree it's bizarre. I'll work on getting a
reproducible test this evening.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Fri, Mar 12, 2004 at 10:35:08PM -0500, William McKee wrote:
>
>>Yeah, that's certainly a concern. I'd like to figure out my
>>misconfiguration issue above then will attempt your proposal to nuke all
>>these old installations and start fresh.
>
>
> Well, I'm now seeing this "Statement unlikely to be reached" error under
> Windows with a fresh ActivePerl 5.8.3 installation. This is starting to
> make me think that it has something to do with the way that I'm invoking
> Apache::Test.
>
> This time I'm getting the following additional message before the
> "unlikely to be reached" error:
>
> [error] failed to resolve handler 'Web::web'
>
> My test is t/response/Web/web.pm.
>
> I went back to be sure that I hadn't overlooked other errors on my Linux
> server and found the following message appearing *after* the "unlikely
> to be reached" error:
>
> [error] Undefined subroutine &Web::web::handler called.
>
> The handler is there and the test works fine if the die statement in
> TestRun.pm is commented out. Still doesn't make any sense to me but
> maybe this addt'l info helps. I'll see about putting together a test
> case for others to try.
Neither to me. Are you sure you get the "Statement unlikely to be reached"
error from the same place? It happens long before the server has started, and
"failed to resolve handler" is an error from the run-time or a server startup.
Again, giving us a tar to play with should be helpful.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Fri, Mar 12, 2004 at 10:35:08PM -0500, William McKee wrote:
> Yeah, that's certainly a concern. I'd like to figure out my
> misconfiguration issue above then will attempt your proposal to nuke all
> these old installations and start fresh.
Well, I'm now seeing this "Statement unlikely to be reached" error under
Windows with a fresh ActivePerl 5.8.3 installation. This is starting to
make me think that it has something to do with the way that I'm invoking
Apache::Test.
This time I'm getting the following additional message before the
"unlikely to be reached" error:
[error] failed to resolve handler 'Web::web'
My test is t/response/Web/web.pm.
I went back to be sure that I hadn't overlooked other errors on my Linux
server and found the following message appearing *after* the "unlikely
to be reached" error:
[error] Undefined subroutine &Web::web::handler called.
The handler is there and the test works fine if the die statement in
TestRun.pm is commented out. Still doesn't make any sense to me but
maybe this addt'l info helps. I'll see about putting together a test
case for others to try.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Fri, Mar 12, 2004 at 07:01:29PM -0800, Stas Bekman wrote:
>
>>Why do you have /usr/lib/libperl.* at all? It's a bad idea to have it in
>>the common path if you have more than one perl installed on the same system.
>>
>>Yes, you always need to rebuild mod_perl with the new version of perl.
>
>
> I must not be building this correctly because I get the following error
> message if I don't create the libperl.so and symlink it into
> /usr/lib/libperl.so:
>
> error while loading shared libraries: libperl.so: cannot open shared
> object file: No such file or directory
>
> I can't find anything about this error in the docs or via Google. Would
> appreciate any insights you may have.
that's when you start apache/mp, right? You need to remove that library and
then rebuild mod_perl. It should now find the library under
/usr/local/lib/perl5/.../libperl.so
>>All I'm worried about is that you may have too many perls installed under
>>the same tree or on the same system, and when you use them they get
>>intermixed causing weird problems. So I'd suggest to completely nuke (after
>>backuping) /usr/local/lib/perl5 and any other places you may have remains
>>of perl including libperl.* and install a fresh perl, rebuild mod_perl and
>>then give it a try.
>
>
> Yeah, that's certainly a concern. I'd like to figure out my
> misconfiguration issue above then will attempt your proposal to nuke all
> these old installations and start fresh.
at least move them into some safe location (like some foo dir under your home
directory).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Fri, Mar 12, 2004 at 07:01:29PM -0800, Stas Bekman wrote:
> Why do you have /usr/lib/libperl.* at all? It's a bad idea to have it in
> the common path if you have more than one perl installed on the same system.
>
> Yes, you always need to rebuild mod_perl with the new version of perl.
I must not be building this correctly because I get the following error
message if I don't create the libperl.so and symlink it into
/usr/lib/libperl.so:
error while loading shared libraries: libperl.so: cannot open shared
object file: No such file or directory
I can't find anything about this error in the docs or via Google. Would
appreciate any insights you may have.
> All I'm worried about is that you may have too many perls installed under
> the same tree or on the same system, and when you use them they get
> intermixed causing weird problems. So I'd suggest to completely nuke (after
> backuping) /usr/local/lib/perl5 and any other places you may have remains
> of perl including libperl.* and install a fresh perl, rebuild mod_perl and
> then give it a try.
Yeah, that's certainly a concern. I'd like to figure out my
misconfiguration issue above then will attempt your proposal to nuke all
these old installations and start fresh.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Thu, Mar 11, 2004 at 04:25:42PM -0800, Stas Bekman wrote:
>
>>OK, please let us know once you get a clean build and if it's still failing
>>we will take it from there. Thanks.
>
>
> OK, finally got Perl 5.8.3 properly built. Unfortunately, my tests are
> still failing. However, this version of Perl is compiled with O3. I'd
> like to try your suggestion of using O2 but am not sure how all of the
> libraries tie together.
>
> Right now, I find that I have to build the shared lib via -Duseshrplib
> then create a symbolic link from /usr/lib/libperl.so back to the right
> version (currently
> /usr/local/lib/perl5/5.8.3/i686-linux/CORE/libperl.so. I do the same for
> libperl.a. If I build Perl with O2, will the .a and .so files have this
> setting? Will I need to rebuild modperl or will it begin using the .so
> with the new setting?
Why do you have /usr/lib/libperl.* at all? It's a bad idea to have it in the
common path if you have more than one perl installed on the same system.
Yes, you always need to rebuild mod_perl with the new version of perl.
> As you can see, I'm rather confused about how all of these files fit
> together. I did read your discussion of installing mp at
> perl.apache.org. However, there were not enough low-level details for me
> to fit all of this together.
All I'm worried about is that you may have too many perls installed under the
same tree or on the same system, and when you use them they get intermixed
causing weird problems. So I'd suggest to completely nuke (after backuping)
/usr/local/lib/perl5 and any other places you may have remains of perl
including libperl.* and install a fresh perl, rebuild mod_perl and then give
it a try.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Thu, Mar 11, 2004 at 04:25:42PM -0800, Stas Bekman wrote:
> OK, please let us know once you get a clean build and if it's still failing
> we will take it from there. Thanks.
OK, finally got Perl 5.8.3 properly built. Unfortunately, my tests are
still failing. However, this version of Perl is compiled with O3. I'd
like to try your suggestion of using O2 but am not sure how all of the
libraries tie together.
Right now, I find that I have to build the shared lib via -Duseshrplib
then create a symbolic link from /usr/lib/libperl.so back to the right
version (currently
/usr/local/lib/perl5/5.8.3/i686-linux/CORE/libperl.so. I do the same for
libperl.a. If I build Perl with O2, will the .a and .so files have this
setting? Will I need to rebuild modperl or will it begin using the .so
with the new setting?
As you can see, I'm rather confused about how all of these files fit
together. I did read your discussion of installing mp at
perl.apache.org. However, there were not enough low-level details for me
to fit all of this together.
Thanks for any advice,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Thu, Mar 11, 2004 at 02:19:46PM -0800, Stas Bekman wrote:
> You mean the current cvs without any patches starts just fine. It's only
> when you run tests you get this problem?
Yep that's what I'm seeing. I reinstalled A::T from CPAN just to confirm
this since I've been messing with that TestRun.pm module quite a bit.
Running t/TEST -start works w/o a problem. It's only when I do -run or
call t/TEST (on it's own or specifying the tests).
> >So, I uncommented the B::Concise line and here's the output:
>
> Before you uncommented B::Conside, was it failing?
Yes.
> It's still pretty foreign to me too ;)
That's not very comforting <g>!
Cheers!
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
[...]
> OK, I was up all night last night and am stopping here for the night.
> I'll rebuild mod_perl tomorrow and try again. I don't suspect this will
> make any difference since these messages started coming up when I was
> running 5.8.2. It's worth a try though.
OK, please let us know once you get a clean build and if it's still failing we
will take it from there. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Thu, Mar 11, 2004 at 02:19:46PM -0800, Stas Bekman wrote:
> You mean the current cvs without any patches starts just fine. It's only
> when you run tests you get this problem?
Here's something to chew on. I appear to have several copies of
TestRun.pm installed on my system due to recompiling Perl. While trying
to "fix" my system (i.e., cook the TestRun.pm file) so that I can get
back to paying the bills, I came across the following discrepancy
between @INC settings.
The following is the error message I'm getting:
Can't locate Apache/TestRun.pm in @INC (@INC contains:
/home/quicktel/QT-Web/t /home/quicktel/QT-Web/blib/lib
/home/quicktel/QT-Web/blib/arch /home/quicktel/QT-Web/t/response
/usr/local/lib/perl5/5.8.2/i686-linux /usr/local/lib/perl5/5.8.2
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux
/usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl
/usr/share/perl5/ /home/quicktel/QT-Web/t/
/home/quicktel/QT-Web/t/lib/perl)
Here's the @INC from running perl -V:
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Mar 11 2004 05:52:10
@INC:
/usr/local/lib/perl5/5.8.3/i686-linux
/usr/local/lib/perl5/5.8.3
/usr/local/lib/perl5/site_perl/5.8.3/i686-linux
/usr/local/lib/perl5/site_perl/5.8.3
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux
/usr/local/lib/perl5/site_perl/5.8.2
/usr/local/lib/perl5/site_perl
.
The 5.8.3 branch isn't even showing up in the project where I'm working.
I tried running 'make clean' and rebuilding via perl Makefile.PL but
that made no difference. Also a 'make realclean' had no effect on the
path. It's almost acting like the server is running a different perl
binary. Turns out it is because I've been manually linking /usr/bin/perl
to /usr/local/bin/perl5.8.x.
Unfortunately, fixing that oversite has not appeared to make any
difference in the error message meaning that the version of Perl running
Apache is 5.8.2. Dang, that means I need to rebuild mod_perl. I always
forget that step.
OK, I was up all night last night and am stopping here for the night.
I'll rebuild mod_perl tomorrow and try again. I don't suspect this will
make any difference since these messages started coming up when I was
running 5.8.2. It's worth a try though.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Thu, Mar 11, 2004 at 10:32:08AM -0800, Stas Bekman wrote:
>
>>rgs suggested to try B::Concise, which show you what the opcode tree looks
>>like. Try the patch below. Does it still fail as before? (all I did is just
>>commenting out some redundant code, which will not prevent us from running.
>>If it does fail the same way, uncomment the line:
>>
>> #B::Concise::compile(__PACKAGE__."::set_ulimit_via_sh")->();
>>
>>run:
>>
>>% t/TEST -start
>>
>>and post the output. Thanks.
>
>
> I had troubles applying the patch (I was using `patch -u -p0 < TestRun.pm.diff`),
> so just manually made the changes. Not much to report as the server
> started up with no errors. I went back and uncommented the lines in
> set_ulimit_via_sh and tried starting the server. It starts up fine.
You mean the current cvs without any patches starts just fine. It's only when
you run tests you get this problem?
> I figured that my system was about to make a liar out of me but when I
> ran the tests, I got the error. Furthermore, if I commented ou the lines
> in set_ulimit_via_sh as per the patch you sent, I continue to get the
> error.
>
> So, I uncommented the B::Concise line and here's the output:
Before you uncommented B::Conside, was it failing?
> I hope this helps someone understand what's happening on my end. I'm
> afraid it's pretty foreign to me since I have not studied the Perl
> internals. Let me know if I can provide any further testing.
It's still pretty foreign to me too ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Thu, Mar 11, 2004 at 10:32:08AM -0800, Stas Bekman wrote:
> rgs suggested to try B::Concise, which show you what the opcode tree looks
> like. Try the patch below. Does it still fail as before? (all I did is just
> commenting out some redundant code, which will not prevent us from running.
> If it does fail the same way, uncomment the line:
>
> #B::Concise::compile(__PACKAGE__."::set_ulimit_via_sh")->();
>
> run:
>
> % t/TEST -start
>
> and post the output. Thanks.
I had troubles applying the patch (I was using `patch -u -p0 < TestRun.pm.diff`),
so just manually made the changes. Not much to report as the server
started up with no errors. I went back and uncommented the lines in
set_ulimit_via_sh and tried starting the server. It starts up fine.
I figured that my system was about to make a liar out of me but when I
ran the tests, I got the error. Furthermore, if I commented ou the lines
in set_ulimit_via_sh as per the patch you sent, I continue to get the
error.
So, I uncommented the B::Concise line and here's the output:
-----------------------------------------------
Apache::TestRun::set_ulimit_via_sh:
w <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->w
1 <;> nextstate(Apache::TestRun -413 TestRun.pm:616) v/2 ->2
- <1> null vK/1 ->9
6 <|> and(other->7) vK/1 ->9
5 <2> helem sK/2 ->6
3 <1> rv2hv sKR/3 ->4
2 <$> gv(*ENV) s ->3
4 <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->5
8 <@> return K ->9
7 <0> pushmark s ->8
9 <;> nextstate(Apache::TestRun -413 TestRun.pm:619) v/2 ->a
f <2> sassign vKS/2 ->g
a <$> const(IV 1) s ->b
e <2> helem sKRM*/2 ->f
c <1> rv2hv sKR/3 ->d
b <$> gv(*ENV) s ->c
d <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->e
g <;> nextstate(Apache::TestRun -413 TestRun.pm:633) v/2 ->h
- <1> ex-stringify sK/17 ->k
- <0> ex-pushmark s ->h
j <2> concat[$original_command:FAKE] sK/TARGMY,2 ->k
h <$> const(PV "ulimit -c unlimited; ") s ->i
i <0> padsv[$original_command:FAKE] s ->j
k <;> nextstate(Apache::TestRun -413 TestRun.pm:635) v/2 ->l
n <@> exec[t4] vK ->o
l <0> pushmark s ->m
m <0> padsv[$original_command:FAKE] l ->n
o <;> nextstate(Apache::TestRun -413 TestRun.pm:636) v/2 ->p
v <@> die[t8] sK/1 ->w
p <0> pushmark s ->q
- <1> ex-stringify sK/1 ->v
- <0> ex-pushmark s ->q
u <2> concat[t6] sKS/2 ->v
s <2> concat[t5] sK/2 ->t
q <$> const(PV "exec ") s ->r
r <0> padsv[$original_command:FAKE] s ->s
t <$> const(PV " has failed") s ->u
Apache::TestRun::set_ulimit_via_sh:
w <1> leavesub[1 ref] K/REFC,1 ->(end)
- <@> lineseq KP ->w
1 <;> nextstate(Apache::TestRun -413 TestRun.pm:616) v/2 ->2
- <1> null vK/1 ->9
6 <|> and(other->7) vK/1 ->9
5 <2> helem sK/2 ->6
3 <1> rv2hv sKR/3 ->4
2 <$> gv(*ENV) s ->3
4 <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->5
8 <@> return K ->9
7 <0> pushmark s ->8
9 <;> nextstate(Apache::TestRun -413 TestRun.pm:619) v/2 ->a
f <2> sassign vKS/2 ->g
a <$> const(IV 1) s ->b
e <2> helem sKRM*/2 ->f
c <1> rv2hv sKR/3 ->d
b <$> gv(*ENV) s ->c
d <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->e
g <;> nextstate(Apache::TestRun -413 TestRun.pm:633) v/2 ->h
- <1> ex-stringify sK/17 ->k
- <0> ex-pushmark s ->h
j <2> concat[$original_command:FAKE] sK/TARGMY,2 ->k
h <$> const(PV "ulimit -c unlimited; ") s ->i
i <0> padsv[$original_command:FAKE] s ->j
k <;> nextstate(Apache::TestRun -413 TestRun.pm:635) v/2 ->l
n <@> exec[t4] vK ->o
l <0> pushmark s ->m
m <0> padsv[$original_command:FAKE] l ->n
o <;> nextstate(Apache::TestRun -413 TestRun.pm:636) v/2 ->p
v <@> die[t8] sK/1 ->w
p <0> pushmark s ->q
- <1> ex-stringify sK/1 ->v
- <0> ex-pushmark s ->q
u <2> concat[t6] sKS/2 ->v
s <2> concat[t5] sK/2 ->t
q <$> const(PV "exec ") s ->r
r <0> padsv[$original_command:FAKE] s ->s
t <$> const(PV " has failed") s ->u
-----------------------------------------------
I hope this helps someone understand what's happening on my end. I'm
afraid it's pretty foreign to me since I have not studied the Perl
internals. Let me know if I can provide any further testing.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
rgs suggested to try B::Concise, which show you what the opcode tree looks
like. Try the patch below. Does it still fail as before? (all I did is just
commenting out some redundant code, which will not prevent us from running. If
it does fail the same way, uncomment the line:
#B::Concise::compile(__PACKAGE__."::set_ulimit_via_sh")->();
run:
% t/TEST -start
and post the output. Thanks.
Index: lib/Apache/TestRun.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.156
diff -u -r1.156 TestRun.pm
--- lib/Apache/TestRun.pm 4 Mar 2004 05:51:31 -0000 1.156
+++ lib/Apache/TestRun.pm 11 Mar 2004 18:29:52 -0000
@@ -612,26 +612,26 @@
}
sub set_ulimit_via_sh {
- return if Apache::TestConfig::WINFU;
+# return if Apache::TestConfig::WINFU;
return if $ENV{APACHE_TEST_ULIMIT_SET};
- my $binsh = '/bin/sh';
- return unless -e $binsh;
+# my $binsh = '/bin/sh';
+# return unless -e $binsh;
$ENV{APACHE_TEST_ULIMIT_SET} = 1;
- my $sh = Symbol::gensym();
- open $sh, "echo ulimit -a | $binsh|" or die;
- local $_;
- while (<$sh>) {
- if (/^core.*unlimited$/) {
- #already set to unlimited
- $ENV{APACHE_TEST_ULIMIT_SET} = 1;
- return;
- }
- }
- close $sh;
+# my $sh = Symbol::gensym();
+# open $sh, "echo ulimit -a | $binsh|" or die;
+# local $_;
+# while (<$sh>) {
+# if (/^core.*unlimited$/) {
+# #already set to unlimited
+# $ENV{APACHE_TEST_ULIMIT_SET} = 1;
+# return;
+# }
+# }
+# close $sh;
$original_command = "ulimit -c unlimited; $original_command";
- warning "setting ulimit to allow core files\n$original_command";
+ #warning "setting ulimit to allow core files\n$original_command";
exec $original_command;
die "exec $original_command has failed"; # shouldn't be reached
}
@@ -639,6 +639,10 @@
sub set_ulimit {
my $self = shift;
#return if $self->set_ulimit_via_bsd_resource;
+
+ use B::Concise;
+ #B::Concise::compile(__PACKAGE__."::set_ulimit_via_sh")->();
+
eval { $self->set_ulimit_via_sh };
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Thu, Mar 11, 2004 at 10:01:17AM -0800, Stas Bekman wrote:
> Are you sure it was actually compiled with -02? Did you check 'perl -V'?
Yep. Here's my latest perl -V:
------------------------
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.4.23, archname=i686-linux
uname='linux vulcan 2.4.23 #1 wed dec 3 22:52:28 est 2003 i686 gnulinux '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Mar 11 2004 05:52:10
@INC:
/usr/local/lib/perl5/5.8.3/i686-linux
/usr/local/lib/perl5/5.8.3
/usr/local/lib/perl5/site_perl/5.8.3/i686-linux
/usr/local/lib/perl5/site_perl/5.8.3
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux
/usr/local/lib/perl5/site_perl/5.8.2
/usr/local/lib/perl5/site_perl
.
-----------------------
> No, that's not what I was suggesting. I suggested that you take the failing
> A-T as is, and start cutting chunks of the code leading to failure and
> retrying, untill you get a minimal case. This is much better than starting
> from the other side. Using that approach you have a constant failure, and
> you know that removing some code doesn't affect it.
I follow you. Will give it a go. Thanks for pushing me to find the root
of the problem.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Mar 10, 2004 at 11:46:02PM -0800, Stas Bekman wrote:
>
>>> optimize='-O3',
>>
>>that could be your problem. Try rebuilding with -02 instead.
>
>
> Hi Stas,
>
> Well, I tried recompiling 5.8.2 with optimize=02. No go.
> I tried to compile 5.8.3 (with O3) - no good.
> I tried to compile 5.8.3 (with O2) - no good.
Are you sure it was actually compiled with -02? Did you check 'perl -V'?
> I'm just going to comment it out for now. At least I'm up to 5.8.3 now
> ;).
That would be a pain, won't it. Let's try to nail it down, continueing where
we started:
>>Since, I can't reproduce it, I'm not sure what is abnormal about your perl,
>>I'd suggest to start truncating the code that fails, till you get to the
>>smallest possible case which you will be able to reproduce in a standalone
>>script. Then we can ask p5p if there is some sort of bug, triggered in
>>certain cases.
>
>
> I copied the entire list of modules and the set_ulimit_via_sh function
> into a test script but was unable to reproduce the problem. Also tried
> messing with eval{} to no avail.
No, that's not what I was suggesting. I suggested that you take the failing
A-T as is, and start cutting chunks of the code leading to failure and
retrying, untill you get a minimal case. This is much better than starting
from the other side. Using that approach you have a constant failure, and you
know that removing some code doesn't affect it.
> I was able to find another poor soul who has experienced my pain[1].
> Unfortunately there was no solution. Found several threads from back in
> the mid-90's which addressed several problems before the die, warn and
> carp statements were allowed to come after an exec w/o triggering the
> warning message. Still not enough to help me reproduce the error when
> running with TEST.
Once we have a standalone short test case, we can ask at p5p.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Wed, Mar 10, 2004 at 11:46:02PM -0800, Stas Bekman wrote:
> > optimize='-O3',
>
> that could be your problem. Try rebuilding with -02 instead.
Hi Stas,
Well, I tried recompiling 5.8.2 with optimize=02. No go.
I tried to compile 5.8.3 (with O3) - no good.
I tried to compile 5.8.3 (with O2) - no good.
I'm just going to comment it out for now. At least I'm up to 5.8.3 now
;).
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Mar 10, 2004 at 10:41:15PM -0800, Stas Bekman wrote:
>
>>% perl -V
[...]
> optimize='-O3',
that could be your problem. Try rebuilding with -02 instead.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Wed, Mar 10, 2004 at 10:41:15PM -0800, Stas Bekman wrote:
> % perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
Platform:
osname=linux, osvers=2.4.23, archname=i686-linux
uname='linux vulcan 2.4.23 #1 wed dec 3 22:52:28 est 2003 i686 gnulinux '
config_args='-Duseshrplib -Dotherlibdirs=/usr/share/perl5/ -de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/local/lib/perl5/5.8.2/i686-linux/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Dec 16 2003 17:36:57
@INC:
/usr/local/lib/perl5/5.8.2/i686-linux
/usr/local/lib/perl5/5.8.2
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux
/usr/local/lib/perl5/site_perl/5.8.2
/usr/local/lib/perl5/site_perl
/usr/share/perl5/
.
> Since, I can't reproduce it, I'm not sure what is abnormal about your perl,
> I'd suggest to start truncating the code that fails, till you get to the
> smallest possible case which you will be able to reproduce in a standalone
> script. Then we can ask p5p if there is some sort of bug, triggered in
> certain cases.
I copied the entire list of modules and the set_ulimit_via_sh function
into a test script but was unable to reproduce the problem. Also tried
messing with eval{} to no avail.
I was able to find another poor soul who has experienced my pain[1].
Unfortunately there was no solution. Found several threads from back in
the mid-90's which addressed several problems before the die, warn and
carp statements were allowed to come after an exec w/o triggering the
warning message. Still not enough to help me reproduce the error when
running with TEST.
William
[1]
http://mathforum.org/epigone/mason/galdcungjom/r02000200-1028-CA6748AE3FB111D892A600039375B1D6@%5B192.168.2.10%5D
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Wed, Mar 10, 2004 at 02:42:45PM -0800, Stas Bekman wrote:
>
>>That's strange. What kind of Perl build do you have?
>
>
> It's 5.8.2 running under Debian stable. I compiled it myself (which
> could attribute to the problem!).
% perl -V
?
>>Do you get this problem when running:
>>
>>% perl -lwe 'use warnings; exec "echo ok"; die "should not be reached"'
>
>
> No problems. I tried playing with taint and some other settings but
> still no problems.
I guess, there are other things that affect it. I'd look for things like eval
{} blocks.
Since, I can't reproduce it, I'm not sure what is abnormal about your perl,
I'd suggest to start truncating the code that fails, till you get to the
smallest possible case which you will be able to reproduce in a standalone
script. Then we can ask p5p if there is some sort of bug, triggered in certain
cases.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by William McKee <wi...@knowmad.com>.
On Wed, Mar 10, 2004 at 02:42:45PM -0800, Stas Bekman wrote:
> That's strange. What kind of Perl build do you have?
It's 5.8.2 running under Debian stable. I compiled it myself (which
could attribute to the problem!).
> According to the exec manpage this is perfectly correct code:
I see what you mean.
> Do you get this problem when running:
>
> % perl -lwe 'use warnings; exec "echo ok"; die "should not be reached"'
No problems. I tried playing with taint and some other settings but
still no problems.
If it matters, the library is located in the following path:
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux/Apache/TestRun.pm
Sorry I cannot provide more details. Let me know if you need any more
info. For now, I'm guessing this is an environmental problem on my side.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> Hi Stas,
>
> I recently upgraded my workstation for A::T 1.07 to 1.09. Immediately
> upon doing so, I started to receive test failures. It turns out that
> these failures were due to lines 613 and 1573 of Apache::TestRun. The
> error was actually a warning as follows:
>
> Statement unlikely to be reached at
> /usr/local/lib/perl5/site_perl/5.8.2/i686-linux/Apache/TestRun.pm line
> 613.
>
> However, following the examples I've seen for TEST.PL, I had the
> following line in my TEST script:
>
> use warnings FATAL => 'all';
>
> This caused the tests to fail. I tried reinstalling Apache::Test 1.07
> and 1.08 but neither made any difference. I don't know why this started
> showing up in 1.09, but it seems like it should be removed. I've
> attached a diff that comments out these lines.
That's strange. What kind of Perl build do you have? According to the exec
manpage this is perfectly correct code:
exec PROGRAM LIST
The "exec" function executes a system command and never
returns-- use "system" instead of "exec" if you want it to
return. It fails and returns false only if the command does
not exist and it is executed directly instead of via your sys-
tem's command shell (see below).
Since it's a common mistake to use "exec" instead of "system",
Perl warns you if there is a following statement which isn't
"die", "warn", or "exit" (if "-w" is set - but you always do
that). If you really want to follow an "exec" with some other
statement, you can use one of these styles to avoid the warn-
ing:
exec ('foo') or print STDERR "couldn't exec foo: $!";
{ exec ('foo') }; print STDERR "couldn't exec foo: $!";
so:
exec $foo;
die "shouldn't be reached";
should generate no warnings.
Do you get this problem when running:
% perl -lwe 'use warnings; exec "echo ok"; die "should not be reached"'
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com