You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2005/02/03 12:29:24 UTC
ithreads.t again
Towards the end of last year I had the following test sequence failing:
modules/reload.t perl/api.t perl/ithreads.t
After ages trying I finally come up with an obscure change which fixed
it
(http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=110302656132092&w=2).
Retrying things again now, I find that while the above sequence does
indeed still succeed, the following sequence (with one extra test) fails
as before:
filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
As before, ithreads.t causes the (only) Apache.exe to crash, but this
time I do get some output in the error log, albeit from the in_error.t test:
[Thu Feb 03 11:20:32 2005] [error] [client 127.0.0.1] This filter must
die at C:\\Temp\\mod_perl-2.0\\t\\filter/TestFilter/in_error.pm line 26.\n
[Thu Feb 03 11:20:32 2005] [error] [client 127.0.0.1]
Apache::RequestIO::read: (120001) filter handler has failed at
C:\\Temp\\mod_perl-2.0\\t\\filter/TestFilter/in_error.pm line 41
Are these messages to be expected normally, or are they possibly the
cause of the subsequent ithreads.t failure?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>[...]
>
>
>>One thought that I just about this stuff: I know that Linux users have
>>always been unable to reproduce this behaviour. Which malloc() are you
>>using? I'm using Perl's malloc() now (although admittedly I was using
>>the system malloc() before). If you're using the system malloc() it
>>might just be worth a try with Perl's malloc() instead to see if it
>>makes any difference.
>>
>>
>
>I'll try to build one with perl's malloc over the weekend and will let you
>know how it goes.
>
Thanks.
One other idea that might be worth looking into: could it be something
to do with tainting?
The reason that I suggest this is that t/filter/TestFilter/in_error.pm
contains this:
# cause taint problems, as there was a bug (panic: POPSTACK)
# caused when APR/Error.pm was attempted to be loaded from
# $r->read() when the latter was trying to croak about the failed
# read, due to the filter returning 500
eval { system('echo', 'hello') };
and if I comment-out that eval {} line then the failing test sequence
(filter/in_error modules/reload perl/api perl/ithreads) now succeeds
(with no premature frees / leaked scalars). There was some discussion
about the POPSTACK bug referred to above here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&w=2&r=1&s=POPSTACK&q=b.
I didn't follow it all, but it seems to relate to the timing of loading
APR::Error. That could also be relevant, given that the warnings
causing my ithreads crash relate to the stringification of an APR:Error
object. Was the APR::Error loading issue ever fully resolved?
Furthermore, here's another test sequence that fails: filter/out_str_lc
modules/reload perl/api perl/ithreads. Again, the filter test in that
sequence involves tainting. If I make the following change to remove
the tainting:
Index: t/filter/TestFilter/out_str_lc.pm
==================================================================
--- t/filter/TestFilter/out_str_lc.pm (revision 151330)
+++ t/filter/TestFilter/out_str_lc.pm (working copy)
@@ -14,9 +14,9 @@
while ($filter->read(my $buffer, 1024)) {
- # test that read() returns tainted data
- die "read() has returned untainted data"
- unless TestCommon::Utils::is_tainted($buffer);
+ # untaint the data
+ $buffer =~ /^(.*)$/;
+ $buffer = $1;
$filter->print(lc $buffer);
}
then that test sequence now succeeds too.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> One thought that I just about this stuff: I know that Linux users have
> always been unable to reproduce this behaviour. Which malloc() are you
> using? I'm using Perl's malloc() now (although admittedly I was using
> the system malloc() before). If you're using the system malloc() it
> might just be worth a try with Perl's malloc() instead to see if it
> makes any difference.
I'll try to build one with perl's malloc over the weekend and will let you
know how it goes.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Attached.
It won't apply for me, but I've tweaked it manually and committed.
> The test sequence that original patch was meant to fix (modules/reload
> perl/api perl/ithreads) currently passes OK with the attached patch
> applied (i.e. the original patch reverted), as do the two more recently
> failing sequences (filter/in_error modules/reload perl/api
> perl/ithreads, and filter/out_str_lc modules/reload perl/api
> perl/ithreads), although the full test suite still fails if the
> t/ithreads.t tests are included.
same here, but randomly. If I'll have time I'll try to get that win32-like
pool perl patch working again (the one that Jan has submitted in chunks
some time ago) and see if I can reproduce the failure in a more
predictable way.
> The full test suite passes OK if the t/ithreads.t tests are skipped, though.
>>>I wonder if the real cause is anything to do with perlbug 34069 or 24254?
>>>http://rt.perl.org/rt3/index.html?q=34069
>>>http://rt.perl.org/rt3/index.html?q=24254
>>>
>>>
>>
>>well, there are no threads involved there, so it could be something else.
>>
>
> It's the same error message that I've seen, though. Maybe we've just
> been lucky in not seeing anything amiss with non-threaded stuff. The
> bug looks like a double-free error ($_ being freed twice - once by the
> inner loop, once by the outer loop), which could well cause the sort of
> "random" behaviour that we're seeing.
>
> I'd love to get that perl bug fixed and then see if our ithreads.t
> problems go away.
Please let us know the outcome of that thread.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>In fact, I think an earlier change that was made to APR::Error::str() to
>>have it sprintf() into a lexical $str and return that, rather than just
>>doing "return sprintf ...", looks like it was unnecessary. Both of the
>>above test sequences still succeed at the moment for me even with that
>>change reverted :( It must just have been a fluke that it fixed things
>>at the time.
>>
>>
>
>in which case we should revert that. Please post a patch that still works
>for you.
>
>
Attached.
The test sequence that original patch was meant to fix (modules/reload
perl/api perl/ithreads) currently passes OK with the attached patch
applied (i.e. the original patch reverted), as do the two more recently
failing sequences (filter/in_error modules/reload perl/api
perl/ithreads, and filter/out_str_lc modules/reload perl/api
perl/ithreads), although the full test suite still fails if the
t/ithreads.t tests are included.
The full test suite passes OK if the t/ithreads.t tests are skipped, though.
>
>
>>I wonder if the real cause is anything to do with perlbug 34069 or 24254?
>>http://rt.perl.org/rt3/index.html?q=34069
>>http://rt.perl.org/rt3/index.html?q=24254
>>
>>
>
>well, there are no threads involved there, so it could be something else.
>
It's the same error message that I've seen, though. Maybe we've just
been lucky in not seeing anything amiss with non-threaded stuff. The
bug looks like a double-free error ($_ being freed twice - once by the
inner loop, once by the outer loop), which could well cause the sort of
"random" behaviour that we're seeing.
I'd love to get that perl bug fixed and then see if our ithreads.t
problems go away.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: ithreads.t again
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>I've build 5.8.6 with mymalloc, but no difference with any of:
>>
>>t/TEST -v filter/out_str_lc.ṫ modules/reload.t perl/api.t perl/ithreads.t
>>t/TEST -v filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
>>
>
> Shame. Thanks for trying anyway.
>
> Interestingly, neither of the above sequences fail for me at the moment
> either! All that's changed is the addition of the Apache::Reload patch
> to modperl_util.c plus the accompanying test (adding "sub promised;" to
> t/modules/reload.t). Reverting the modperl_util.c change makes no
> difference to this, but reverting the reload.t change makes the failures
> re-appear!
>
> It looks more and more like some random memory corruption, just like the
> random failures that you find on Linux. Maybe Win32 sets thing up in
> memory the same way each time I run the program, but is sensitive to
> very slight changes in the program being run, whereas Linux doesn't even
> set things up the same each time anyway?
Frankly I have no idea.
As mentioned before I'm planning to start writing lots of new tests solely
to excercise mp2/APR API under threads. I'm looking forward to having a
lot of "fun" :)
> In fact, I think an earlier change that was made to APR::Error::str() to
> have it sprintf() into a lexical $str and return that, rather than just
> doing "return sprintf ...", looks like it was unnecessary. Both of the
> above test sequences still succeed at the moment for me even with that
> change reverted :( It must just have been a fluke that it fixed things
> at the time.
in which case we should revert that. Please post a patch that still works
for you.
> I wonder if the real cause is anything to do with perlbug 34069 or 24254?
> http://rt.perl.org/rt3/index.html?q=34069
> http://rt.perl.org/rt3/index.html?q=24254
well, there are no threads involved there, so it could be something else.
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>[...]
>
>
>>One thought that I just about this stuff: I know that Linux users have
>>always been unable to reproduce this behaviour. Which malloc() are you
>>using? I'm using Perl's malloc() now (although admittedly I was using
>>the system malloc() before). If you're using the system malloc() it
>>might just be worth a try with Perl's malloc() instead to see if it
>>makes any difference.
>>
>>
>
>I've build 5.8.6 with mymalloc, but no difference with any of:
>
>t/TEST -v filter/out_str_lc.ṫ modules/reload.t perl/api.t perl/ithreads.t
>t/TEST -v filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
>
Shame. Thanks for trying anyway.
Interestingly, neither of the above sequences fail for me at the moment
either! All that's changed is the addition of the Apache::Reload patch
to modperl_util.c plus the accompanying test (adding "sub promised;" to
t/modules/reload.t). Reverting the modperl_util.c change makes no
difference to this, but reverting the reload.t change makes the failures
re-appear!
It looks more and more like some random memory corruption, just like the
random failures that you find on Linux. Maybe Win32 sets thing up in
memory the same way each time I run the program, but is sensitive to
very slight changes in the program being run, whereas Linux doesn't even
set things up the same each time anyway?
In fact, I think an earlier change that was made to APR::Error::str() to
have it sprintf() into a lexical $str and return that, rather than just
doing "return sprintf ...", looks like it was unnecessary. Both of the
above test sequences still succeed at the moment for me even with that
change reverted :( It must just have been a fluke that it fixed things
at the time.
I wonder if the real cause is anything to do with perlbug 34069 or 24254?
http://rt.perl.org/rt3/index.html?q=34069
http://rt.perl.org/rt3/index.html?q=24254
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: ithreads.t again
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> One thought that I just about this stuff: I know that Linux users have
> always been unable to reproduce this behaviour. Which malloc() are you
> using? I'm using Perl's malloc() now (although admittedly I was using
> the system malloc() before). If you're using the system malloc() it
> might just be worth a try with Perl's malloc() instead to see if it
> makes any difference.
I've build 5.8.6 with mymalloc, but no difference with any of:
t/TEST -v filter/out_str_lc.ṫ modules/reload.t perl/api.t perl/ithreads.t
t/TEST -v filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: ithreads.t again
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>the following sequence (with one extra test) fails
>as before:
>
> filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t
>
>As before, ithreads.t causes the (only) Apache.exe to crash
>
The "crash" really is the same as before. (Have a look at
http://marc.theaimsgroup.com/?t=110141084300003&r=1&w=2 if you need
reminding.)
The server crashes because of the
use warnings FATAL => 'all';
line in ithreads.pm. Commenting that out and inserting this into
ithreads.pm's handler():
close STDERR;
open STDERR, '>C:\\Temp\\stderr.txt';
together with an sv_dump(sv) in threads.xs just before the offending
SvREFCNT_dec(sv) (line 476, in perl 5.8.6) I now get the output in the
attached stderr.txt file.
As you can see, the warning that causes the crash is exactly as before,
so we still haven't fixed it after all :(
Lines 47 and 64 in ithreads.pm, referred to in the stderr.txt output,
are the last lines of the two
my $thr = threads->new(sub {
...
});
blocks.
One thought that I just about this stuff: I know that Linux users have
always been unable to reproduce this behaviour. Which malloc() are you
using? I'm using Perl's malloc() now (although admittedly I was using
the system malloc() before). If you're using the system malloc() it
might just be worth a try with Perl's malloc() instead to see if it
makes any difference.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.