You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2004/12/02 08:09:42 UTC
Re: t/perl/ithreads.t revisited
Stas Bekman wrote:
> Steve Hay wrote:
>
>>>> Next I want you to try cutting off things from startup files and
>>>> httpd.conf, to find whether it's some unrelated module that is
>>>> loaded that causes the problem. I suspect that because the sister
>>>> test t/perl/ithreads2.t doesn't fail, and it runs exactly the same
>>>> code, but inside a dedicated interpreter pool, which doesn't load
>>>> any other modules.
>>>
>>> Will try (again), but I've tried this before and got nowhere with it :(
>>>
>> While trawling through the httpd.conf file I found a couple of what
>> look like errors: Two places say "PERL_ITHREADS" instead of
>> "PERL_USEITHREADS". Correcting these apparent mistakes fixes the
>> broken test sequence previously reported!
>
> [...]
>
>> After making this change I found that reload.t now fails test 2. This
>> patch (against current CVS, since I can't get SVN working) fixes that:
>>
>> Index: t/modules/reload.t
>> ===================================================================
>> RCS file: /home/cvspublic/modperl-2.0/t/modules/reload.t,v
>> retrieving revision 1.4
>> diff -u -u -r1.4 reload.t
>> --- t/modules/reload.t 11 Sep 2004 01:02:28 -0000 1.4
>> +++ t/modules/reload.t 26 Nov 2004 18:05:21 -0000
>> @@ -53,7 +53,7 @@
>> touch_mtime($test_file);
>>
>> {
>> - my $expected = join '', map { "$_:" . uc($_) . "\n" } sort @tests;
>> + my $expected = join '', map { "$_:$_\n" } sort @tests;
>> my $received = get_body($same_interp, \&GET, $location);
>> $skip++ unless defined $received;
>> skip_not_same_interp(
>
That's not a correct fix to the problem. reload.t is apparently now failing for
you, and this patch just ignores the failure.
Can you try t/modules/reload.t with your ITHREAD patch but add:
PerlSetVar ReloadDebug On
to your httpd.conf and see what happens.
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Philippe M. Chiasson wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>>Steve Hay wrote:
>>>
>>>
>>>
>>>
>>>>>>Next I want you to try cutting off things from startup files and
>>>>>>httpd.conf, to find whether it's some unrelated module that is
>>>>>>loaded that causes the problem. I suspect that because the sister
>>>>>>test t/perl/ithreads2.t doesn't fail, and it runs exactly the same
>>>>>>code, but inside a dedicated interpreter pool, which doesn't load
>>>>>>any other modules.
>>>>>>
>>>>>>
>>>>>
>>>>>Will try (again), but I've tried this before and got nowhere with it :(
>>>>>
>>>>>
>>>>>
>>>>
>>>>While trawling through the httpd.conf file I found a couple of what
>>>>look like errors: Two places say "PERL_ITHREADS" instead of
>>>>"PERL_USEITHREADS". Correcting these apparent mistakes fixes the
>>>>broken test sequence previously reported!
>>>>
>>>>
>>>
>>>[...]
>>>
>>>
>>>
>>>
>>>>After making this change I found that reload.t now fails test 2. This
>>>>patch (against current CVS, since I can't get SVN working) fixes that:
>>>>
>>>>Index: t/modules/reload.t
>>>>===================================================================
>>>>RCS file: /home/cvspublic/modperl-2.0/t/modules/reload.t,v
>>>>retrieving revision 1.4
>>>>diff -u -u -r1.4 reload.t
>>>>--- t/modules/reload.t 11 Sep 2004 01:02:28 -0000 1.4
>>>>+++ t/modules/reload.t 26 Nov 2004 18:05:21 -0000
>>>>@@ -53,7 +53,7 @@
>>>>touch_mtime($test_file);
>>>>
>>>>{
>>>>- my $expected = join '', map { "$_:" . uc($_) . "\n" } sort @tests;
>>>>+ my $expected = join '', map { "$_:$_\n" } sort @tests;
>>>> my $received = get_body($same_interp, \&GET, $location);
>>>> $skip++ unless defined $received;
>>>> skip_not_same_interp(
>>>>
>>>>
>>
>>That's not a correct fix to the problem. reload.t is apparently now failing for
>>you, and this patch just ignores the failure.
>>
>
> OK, current state of play is this:
>
> With fresh svn check-out, all tests pass OK if I skip t/perl/ithreads,
> but with t/perl/ithreads the server crashes on that test.
>
> As before, this sequence reliably fails:
>
> perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>
> It still fails with the attached much-shortened conf file. Note that
> I've commented-out a top-level PerlInterpScope directive, in line with
> recent changes. If I re-instate that directive then t/perl/ithreads no
> longer crashes, but t/modules/reload fails as described above.
>
> Are we sure that the PerlInterpScope directive should not be at the
> top-level? If so, then reload.t is OK and we still have ithreads.t to fix.
I think PerlInterpScope just helps to hide the problem. It probably moves
the interpreter back to the pool and a new interpreter is serving other
requests.
I'm just going to make that test skip for now (it is not in the distro
anyway) and later on we need to start working on writing a bunch of new
tests exercising the scoping directives and nail this and other
interpreter context switch problems.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Regarding that warning, perldiag says:
>>
>>"Mortalized values are supposed to be freed by the free_tmps() routine.
>>This indicates that something else is freeing the SV before the
>>free_tmps() routine gets a chance, which means that the free_tmps()
>>routine will be freeing an unreferenced scalar when it does try to free it."
>>
>>Presumably the "something else" that is trying to free the SV's here is
>>simply the wrong interpreter?
>>
>>
>
>Quite possible, since ithreads doesn't set the global context. how about:
>
>
Didn't make any difference :(
>--- ext/threads/threads.xs.orig 2004-12-13 10:19:10.985754535 -0500
>+++ ext/threads/threads.xs 2004-12-13 10:20:04.044543828 -0500
>@@ -432,7 +432,8 @@
> */
> {
> dTHXa(thread->interp);
>-
>+ PERL_SET_CONTEXT(thread->interp);
>+
> /* Here we remove END blocks since they should only run
> in the thread they are created
> */
>
>you will have to apply it manually because of the tab.
>
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Steve Hay wrote:
>
>
>>Anyway, I've made an interesting new discovery: the ithreads.t test
>>crashes the server because ithreads.pm contains "use warnings FATAL =>
>>'all'". Simply commenting-out that line, the skeleton test now succeeds!
>>
>
> Furthermore, the full svn (rev 111694) test suite, with
> t/perl/ithreads.t re-enabled, also works!
Again, /me says, it's just a coincidence, and adding new code elsewhere
will break it again.
> The warnings now appear in
> the console window:
>
> t\perl\ithreads.........................Attempt to free temp
> prematurely: SV 0x8437b04, Perl interpreter: 0x470e764 at
> C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
> Attempt to free temp prematurely: SV 0x84378dc, Perl interpreter:
> 0x470e764 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
> Attempt to free temp prematurely: SV 0x476b4a0, Perl interpreter:
> 0x470e764 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
> Scalars leaked: 3
> Attempt to free temp prematurely: SV 0x83d06e4, Perl interpreter:
> 0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
> Attempt to free temp prematurely: SV 0x83d04bc, Perl interpreter:
> 0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
> Attempt to free temp prematurely: SV 0x4763bd4, Perl interpreter:
> 0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
> Scalars leaked: 3
>
> Lines 44 & 61 are respectively the last lines of these two chunks:
>
> my $thr = threads->new(sub {
> my $tid = threads->self->tid;
> debug "2nd TID is $tid" if defined $tid;
> return 2;
> });
>
> my $thr = threads->new(sub {
> my $tid = threads->self->tid;
> debug "2nd TID is $tid" if defined $tid;
> $counter_priv += $counter_priv for 1..10;
> {
> lock $counter_shar;
> $counter_shar += $counter_shar for 1..10;
> }
> });
>
> Regarding that warning, perldiag says:
>
> "Mortalized values are supposed to be freed by the free_tmps() routine.
> This indicates that something else is freeing the SV before the
> free_tmps() routine gets a chance, which means that the free_tmps()
> routine will be freeing an unreferenced scalar when it does try to free it."
>
> Presumably the "something else" that is trying to free the SV's here is
> simply the wrong interpreter?
Quite possible, since ithreads doesn't set the global context. how about:
--- ext/threads/threads.xs.orig 2004-12-13 10:19:10.985754535 -0500
+++ ext/threads/threads.xs 2004-12-13 10:20:04.044543828 -0500
@@ -432,7 +432,8 @@
*/
{
dTHXa(thread->interp);
-
+ PERL_SET_CONTEXT(thread->interp);
+
/* Here we remove END blocks since they should only run
in the thread they are created
*/
you will have to apply it manually because of the tab.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>Anyway, I've made an interesting new discovery: the ithreads.t test
>crashes the server because ithreads.pm contains "use warnings FATAL =>
>'all'". Simply commenting-out that line, the skeleton test now succeeds!
>
Furthermore, the full svn (rev 111694) test suite, with
t/perl/ithreads.t re-enabled, also works! The warnings now appear in
the console window:
t\perl\ithreads.........................Attempt to free temp
prematurely: SV 0x8437b04, Perl interpreter: 0x470e764 at
C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
Attempt to free temp prematurely: SV 0x84378dc, Perl interpreter:
0x470e764 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
Attempt to free temp prematurely: SV 0x476b4a0, Perl interpreter:
0x470e764 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 44.
Scalars leaked: 3
Attempt to free temp prematurely: SV 0x83d06e4, Perl interpreter:
0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
Attempt to free temp prematurely: SV 0x83d04bc, Perl interpreter:
0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
Attempt to free temp prematurely: SV 0x4763bd4, Perl interpreter:
0x7b522a4 at C:\Temp\mod_perl-2.0\t\response/TestPerl/ithreads.pm line 61.
Scalars leaked: 3
Lines 44 & 61 are respectively the last lines of these two chunks:
my $thr = threads->new(sub {
my $tid = threads->self->tid;
debug "2nd TID is $tid" if defined $tid;
return 2;
});
my $thr = threads->new(sub {
my $tid = threads->self->tid;
debug "2nd TID is $tid" if defined $tid;
$counter_priv += $counter_priv for 1..10;
{
lock $counter_shar;
$counter_shar += $counter_shar for 1..10;
}
});
Regarding that warning, perldiag says:
"Mortalized values are supposed to be freed by the free_tmps() routine.
This indicates that something else is freeing the SV before the
free_tmps() routine gets a chance, which means that the free_tmps()
routine will be freeing an unreferenced scalar when it does try to free it."
Presumably the "something else" that is trying to free the SV's here is
simply the wrong interpreter?
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: [PATCH] Re: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
>>that would need to be a C code that mixes overload in it. I'll try to
>>write one tomorrow. Please remind me if I forget.
>>
>
> That's what I tried to in the 'Foo' module that I sent -- it has some XS
> code playing with $@, together with overload stuff in the .pm file.
Ah, sorry, I've missed the fact that you had an attachement. Hopefully
will have a chance to look at it soonish. Thanks Steve.
--
__________________________________________________________________
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: [PATCH] Re: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>>"-e line 0" means
>>>that it's a C code :) you could just as well dereference a NULL pointer
>>>for this purpose. or use my module for that :)
>>>http://search.cpan.org/dist/Debug-FaultAutoBT/DumpCore.pm
>>>
>>>
>>>
>>>
>>Couldn't build your module on Win32 either :(
>>
>>
>
>This is probably due to the other module in that package :( May be I
>should release it separately. Feel free to send me the error messages
>offlist to see if it's something that can be easily fixed (if you want to
>bother at all).
>
>
I'll have a closer look at what the errors were...
>>>Bizarre. We need to figure out how to reproduce this bug outside modperl
>>>and report to p5p. since this is definitely a bug in perl.
>>>
>>>
>>>
>>>
>>Unless, of course, I'm just being really lucky again. I tried mucking
>>around with the conf files, adding and deleting code here and there and
>>couldn't break it. I'm also encouraged that the whole test suite works,
>>but you never know...
>>
>>I've tried to reproduce this outside of mp2, but haven't had any luck
>>yet. The attached "Foo" module does some overloaded stringification of
>>an error object and then plays around with threads, much like api.t
>>followed by ithreads.t, but so far "make test" just runs cleanly :(
>>
>>Any suggestions how to try to make this sample module break would be
>>welcome.
>>
>>
>
>that would need to be a C code that mixes overload in it. I'll try to
>write one tomorrow. Please remind me if I forget.
>
That's what I tried to in the 'Foo' module that I sent -- it has some XS
code playing with $@, together with overload stuff in the .pm file.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: [PATCH] Re: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Nor me till I tried it. All it does is print an utterly useless message
> in the console:
>
> >perl -e "CORE::dump()"
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> perlport does mention it is not implemented, though.
perlbug it? But on the other hand I think it's going to be deprecated in 5.10.
>>"-e line 0" means
>>that it's a C code :) you could just as well dereference a NULL pointer
>>for this purpose. or use my module for that :)
>>http://search.cpan.org/dist/Debug-FaultAutoBT/DumpCore.pm
>>
>>
>
> Couldn't build your module on Win32 either :(
This is probably due to the other module in that package :( May be I
should release it separately. Feel free to send me the error messages
offlist to see if it's something that can be easily fixed (if you want to
bother at all).
>>Is it somewhere in SvRV(ERRSV)? After all ERRSV is an object here.
>>
>>
>
> I tried sv_dump(SvRV(ERRSV)) and it just showed that it's a hash with 4
> keys. Since we're expecting 4 keys anyway (rc, file, line, func), I
> didn't bother chasing any of them to see if they were it.
Yeah, I did that too. that means that it stores that stringified object
elsewhere
>>Bizarre. We need to figure out how to reproduce this bug outside modperl
>>and report to p5p. since this is definitely a bug in perl.
>>
>>
>
> Unless, of course, I'm just being really lucky again. I tried mucking
> around with the conf files, adding and deleting code here and there and
> couldn't break it. I'm also encouraged that the whole test suite works,
> but you never know...
>
> I've tried to reproduce this outside of mp2, but haven't had any luck
> yet. The attached "Foo" module does some overloaded stringification of
> an error object and then plays around with threads, much like api.t
> followed by ithreads.t, but so far "make test" just runs cleanly :(
>
> Any suggestions how to try to make this sample module break would be
> welcome.
that would need to be a C code that mixes overload in it. I'll try to
write one tomorrow. Please remind me if I forget.
--
__________________________________________________________________
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: [PATCH] Re: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>CORE::dump() doesn't seem to do anything useful in Win32 land :( I
>>tried commenting-out the "$Carp::CarpInternal{+__PACKAGE__}++;" line in
>>APR/Error.pm and then adding:
>>
>>Carp::cluck("str called");
>>
>>inside str(). This only gives me the following in stderr.txt:
>>
>>str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
>> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
>>-e line 0
>>str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
>> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
>>-e line 0
>>str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
>> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
>>-e line 0
>>
>>Line 60 is, of course, the Carp::cluck() call that I've inserted
>>itself. Is there any way to get at what "-e line 0" really is?
>>
>>
>
>Heh, that's why I was asking you to use dump() which would have shown the
>C stack trace. I didn't know dump didn't work on win32.
>
Nor me till I tried it. All it does is print an utterly useless message
in the console:
>perl -e "CORE::dump()"
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
perlport does mention it is not implemented, though.
> "-e line 0" means
>that it's a C code :) you could just as well dereference a NULL pointer
>for this purpose. or use my module for that :)
>http://search.cpan.org/dist/Debug-FaultAutoBT/DumpCore.pm
>
>
Couldn't build your module on Win32 either :(
>
>
>>I was confused where the SV that's being prematurely free()'d was coming
>>from, though. I thought the 'bool' override would just fill in the PV
>>slot of the ERRSV, but it isn't the ERRSV that we're having trouble
>>free()'ing. The sv_dump() quoted at the start of this mail shows that
>>the offending SV *only* contains a PV slot, not any of the other stuff
>>that ERRSV would have, and equally if I sv_dump() ERRSV, even just
>>*after* the SvTRUE() call, it doesn't seem to have a PV slot.
>>
>>
>
>Is it somewhere in SvRV(ERRSV)? After all ERRSV is an object here.
>
>
I tried sv_dump(SvRV(ERRSV)) and it just showed that it's a hash with 4
keys. Since we're expecting 4 keys anyway (rc, file, line, func), I
didn't bother chasing any of them to see if they were it.
>
>
>>So it's like the stringified error was put in a brand new SVPV...
>>
>>Then it hit me (I hope this is right...): it must be the string returned
>>by the str() subroutine itself!
>>
>>
>
>That's correct, that's why I've quoted this function in my email :)
>
>
>
>>Changing the subroutine from what you
>>quoted above to this:
>>
>>sub str {
>> my $str = sprintf "%s: (%d) %s at %s line %d", $_[0]->{func},
>> $_[0]->{rc}, APR::Error::strerror($_[0]->{rc}),
>> $_[0]->{file}, $_[0]->{line};
>> return $str;
>>}
>>
>>i.e. explicitly create a lexical for the $str and then return that,
>>fixes it!
>>
>>
>
>Bizarre. We need to figure out how to reproduce this bug outside modperl
>and report to p5p. since this is definitely a bug in perl.
>
>
Unless, of course, I'm just being really lucky again. I tried mucking
around with the conf files, adding and deleting code here and there and
couldn't break it. I'm also encouraged that the whole test suite works,
but you never know...
I've tried to reproduce this outside of mp2, but haven't had any luck
yet. The attached "Foo" module does some overloaded stringification of
an error object and then plays around with threads, much like api.t
followed by ithreads.t, but so far "make test" just runs cleanly :(
Any suggestions how to try to make this sample module break would be
welcome.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: [PATCH] Re: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> It is the 'bool' overload that's doing the stringification: presumably
> the SvTRUE(sv) call in modperl_errsv()?
I think yes.
> If I comment-out the 'bool' overload line then stderr.txt is now empty,
> and the skeleton tests pass OK, even with the "use warnings FATAL =>
> 'all';" line back in.
Great.
>>(notice that APR::Error is autogenerated, so you may want to modify
>>blib/lib/Apache2/APR/Error.pm if you don't want to rebuild things)
>>
>>alternatively try to add CORE::dump() inside str() above to see who has
>>called the stringification function.
>>
>
> CORE::dump() doesn't seem to do anything useful in Win32 land :( I
> tried commenting-out the "$Carp::CarpInternal{+__PACKAGE__}++;" line in
> APR/Error.pm and then adding:
>
> Carp::cluck("str called");
>
> inside str(). This only gives me the following in stderr.txt:
>
> str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
> -e line 0
> str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
> -e line 0
> str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
> APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
> -e line 0
>
> Line 60 is, of course, the Carp::cluck() call that I've inserted
> itself. Is there any way to get at what "-e line 0" really is?
Heh, that's why I was asking you to use dump() which would have shown the
C stack trace. I didn't know dump didn't work on win32. "-e line 0" means
that it's a C code :) you could just as well dereference a NULL pointer
for this purpose. or use my module for that :)
http://search.cpan.org/dist/Debug-FaultAutoBT/DumpCore.pm
> I was confused where the SV that's being prematurely free()'d was coming
> from, though. I thought the 'bool' override would just fill in the PV
> slot of the ERRSV, but it isn't the ERRSV that we're having trouble
> free()'ing. The sv_dump() quoted at the start of this mail shows that
> the offending SV *only* contains a PV slot, not any of the other stuff
> that ERRSV would have, and equally if I sv_dump() ERRSV, even just
> *after* the SvTRUE() call, it doesn't seem to have a PV slot.
Is it somewhere in SvRV(ERRSV)? After all ERRSV is an object here.
> So it's like the stringified error was put in a brand new SVPV...
>
> Then it hit me (I hope this is right...): it must be the string returned
> by the str() subroutine itself!
That's correct, that's why I've quoted this function in my email :)
> Changing the subroutine from what you
> quoted above to this:
>
> sub str {
> my $str = sprintf "%s: (%d) %s at %s line %d", $_[0]->{func},
> $_[0]->{rc}, APR::Error::strerror($_[0]->{rc}),
> $_[0]->{file}, $_[0]->{line};
> return $str;
> }
>
> i.e. explicitly create a lexical for the $str and then return that,
> fixes it!
Bizarre. We need to figure out how to reproduce this bug outside modperl
and report to p5p. since this is definitely a bug in perl.
> In this case, the string is definitely a lexical variable and evidently
> gets cleaned up exactly as we would expect. In the previous case, I'm
> not entirely clear in my mind about exactly what
>
> sub str {
> sprintf ...
> }
>
> does. Clearly it makes some kind of string and implicitly returns it,
> but I'm not sure what the scope of the SV that it made is. Why on earth
> it would be a problem for me on Win32 and not for you on Linux, I've no
> idea.
remember that it did fail on linux too, but very randomly (but the warning
message was the same. It's just I was never able to debug it, because it
was always random.
> I've never seen anything like this before, but then again, I've never
> liked the "falling off the end" return style anyway -- I always create
> lexicals and explcitily return them.
>
> Anyway, svn @ revision 111817 + the attached patch passes all tests for me!
Good to see this painful issue resolved, Steve. Thanks a lot for this
amazing persistence. I'll commit your patch when svn comes up (it's down
now) and then if things go well we will re-add these tests to the distro.
--
__________________________________________________________________
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
[PATCH] Re: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>
>>I now get this in the stderr.txt file:
>>
>>SV = PV(0x31f64d0) at 0x31960b8
>> REFCNT = 1
>> FLAGS = (TEMP,POK,pPOK)
>> PV = 0x31f7ed4 "ModPerl::Util::exit: (120000) exit was called at
>>C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
>> CUR = 98
>> LEN = 99
>>Attempt to free temp prematurely: SV 0x31960b8, Perl interpreter:
>>0x2b51784 at
>>C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 56.
>>Scalars leaked: 1
>>
>>
>
>Now when the handler returns its status goes through modperl_errsv() which
>has a special case for objects thrown from exit()'s call.
>
>int modperl_errsv(pTHX_ int status, request_rec *r, server_rec *s)
>{
> SV *sv = ERRSV;
> STRLEN n_a;
>
> if (SvTRUE(sv)) {
> if (sv_derived_from(sv, "APR::Error") &&
> SvIVx(sv) == MODPERL_RC_EXIT) {
> /* ModPerl::Util::exit was called */
> return OK;
> }
>
>the actual stringification of the exception object into a string:
>
>"ModPerl::Util::exit: (120000) exit was called at
>C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
>
>happens only if something tries to stringify $@ or bool'ify. But this
>stringification is done by a perl code in APR::Error, which overloads:
>
>use overload
> nomethod => \&fatal,
> 'bool' => \&str,
> '==' => \&num,
> '0+' => \&num,
> '""' => \&str;
>
>sub str {
> sprintf "%s: (%d) %s at %s line %d", $_[0]->{func},
> $_[0]->{rc}, APR::Error::strerror($_[0]->{rc}),
> $_[0]->{file}, $_[0]->{line};
>}
>
>and this is what your SV's PV string looks like. So there is no really any
>C code here that could get the refcounting wrong.
>
>may be this is something triggered by overload? what happens if you
>comment out the overload part?
>
>
It is the 'bool' overload that's doing the stringification: presumably
the SvTRUE(sv) call in modperl_errsv()?
If I comment-out the 'bool' overload line then stderr.txt is now empty,
and the skeleton tests pass OK, even with the "use warnings FATAL =>
'all';" line back in.
>(notice that APR::Error is autogenerated, so you may want to modify
>blib/lib/Apache2/APR/Error.pm if you don't want to rebuild things)
>
>alternatively try to add CORE::dump() inside str() above to see who has
>called the stringification function.
>
CORE::dump() doesn't seem to do anything useful in Win32 land :( I
tried commenting-out the "$Carp::CarpInternal{+__PACKAGE__}++;" line in
APR/Error.pm and then adding:
Carp::cluck("str called");
inside str(). This only gives me the following in stderr.txt:
str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
-e line 0
str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
-e line 0
str called at C:/apache2/perl5/site/lib/APR/Error.pm line 60
APR::Error::str('APR::Error=HASH(0x2b2107c)', 'undef', '') called at
-e line 0
Line 60 is, of course, the Carp::cluck() call that I've inserted
itself. Is there any way to get at what "-e line 0" really is?
I was confused where the SV that's being prematurely free()'d was coming
from, though. I thought the 'bool' override would just fill in the PV
slot of the ERRSV, but it isn't the ERRSV that we're having trouble
free()'ing. The sv_dump() quoted at the start of this mail shows that
the offending SV *only* contains a PV slot, not any of the other stuff
that ERRSV would have, and equally if I sv_dump() ERRSV, even just
*after* the SvTRUE() call, it doesn't seem to have a PV slot.
So it's like the stringified error was put in a brand new SVPV...
Then it hit me (I hope this is right...): it must be the string returned
by the str() subroutine itself! Changing the subroutine from what you
quoted above to this:
sub str {
my $str = sprintf "%s: (%d) %s at %s line %d", $_[0]->{func},
$_[0]->{rc}, APR::Error::strerror($_[0]->{rc}),
$_[0]->{file}, $_[0]->{line};
return $str;
}
i.e. explicitly create a lexical for the $str and then return that,
fixes it!
In this case, the string is definitely a lexical variable and evidently
gets cleaned up exactly as we would expect. In the previous case, I'm
not entirely clear in my mind about exactly what
sub str {
sprintf ...
}
does. Clearly it makes some kind of string and implicitly returns it,
but I'm not sure what the scope of the SV that it made is. Why on earth
it would be a problem for me on Win32 and not for you on Linux, I've no
idea.
I've never seen anything like this before, but then again, I've never
liked the "falling off the end" return style anyway -- I always create
lexicals and explcitily return them.
Anyway, svn @ revision 111817 + the attached patch passes all tests for me!
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> I now get this in the stderr.txt file:
>
> SV = PV(0x31f64d0) at 0x31960b8
> REFCNT = 1
> FLAGS = (TEMP,POK,pPOK)
> PV = 0x31f7ed4 "ModPerl::Util::exit: (120000) exit was called at
> C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
> CUR = 98
> LEN = 99
> Attempt to free temp prematurely: SV 0x31960b8, Perl interpreter:
> 0x2b51784 at
> C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 56.
> Scalars leaked: 1
Getting back to the exit function itself called from Apache::Test::plan().
This sv thing shouldn't have really happened. How does exit works in mp2:
void modperl_perl_exit(pTHX_ int status)
{
ENTER;
SAVESPTR(PL_diehook);
PL_diehook = Nullsv;
modperl_croak(aTHX_ MODPERL_RC_EXIT, "ModPerl::Util::exit");
}
so exit calls modperl_croak(), which creates an APR::Error exception
object and throws it via Perl_croak(aTHX_ Nullch);
Now when the handler returns its status goes through modperl_errsv() which
has a special case for objects thrown from exit()'s call.
int modperl_errsv(pTHX_ int status, request_rec *r, server_rec *s)
{
SV *sv = ERRSV;
STRLEN n_a;
if (SvTRUE(sv)) {
if (sv_derived_from(sv, "APR::Error") &&
SvIVx(sv) == MODPERL_RC_EXIT) {
/* ModPerl::Util::exit was called */
return OK;
}
the actual stringification of the exception object into a string:
"ModPerl::Util::exit: (120000) exit was called at
C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
happens only if something tries to stringify $@ or bool'ify. But this
stringification is done by a perl code in APR::Error, which overloads:
use overload
nomethod => \&fatal,
'bool' => \&str,
'==' => \&num,
'0+' => \&num,
'""' => \&str;
sub str {
sprintf "%s: (%d) %s at %s line %d", $_[0]->{func},
$_[0]->{rc}, APR::Error::strerror($_[0]->{rc}),
$_[0]->{file}, $_[0]->{line};
}
and this is what your SV's PV string looks like. So there is no really any
C code here that could get the refcounting wrong.
may be this is something triggered by overload? what happens if you
comment out the overload part?
(notice that APR::Error is autogenerated, so you may want to modify
blib/lib/Apache2/APR/Error.pm if you don't want to rebuild things)
alternatively try to add CORE::dump() inside str() above to see who has
called the stringification function.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>you mean re-enable t/perl/ithreads.t, skip api.t and run:
>>
>>% t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>>
>>just did that, and see no problem.
>>
>>
>
> Yes. But how did you skip api.t? I meant edit
> t/response/TestPerl/api.pm so that some condition is not met in the test
> plan so that the chunk of code above gets run. The test plan is
> expressed as:
>
> plan $r, tests => 2,
> need { "getppid() is not implemented on Win32"
> => !Apache::Build::WIN32(),
> "getppid() is having problems with perl 5.6"
> => !($] < 5.008),
> };
>
> so change this to make it skip for you. (As opposed to just creating a
> t/SKIP file, which wouldn't involve the "exit" code above.)
That's exactly what I did (not t/SKIP). Now looking at modperl_perl_exit.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>
>>>>No, it's something in the mp2 test setup. If I just start my installed
>>>>Apache2/mp2 setup then I get two Apache.exe's as expected. I'll try to
>>>>see what the difference is.
>>>>
>>>>
>>>>
>>>
>>>Got it. We made an exception for Win32 to always run in one-process
>>>mode because otherwise we couldn't relaibly stop both the parent and
>>>child processes. See the call to Win32::Process::Create() in
>>>Apache::TestServer::start().
>>>
>>>It does have the undesirable side-effect that we have seen in this
>>>thread, though, namely that if one test causes the single Apache.exe
>>>process to exit for whatever reason then all subsequent tests will fail
>>>since they now have no server to connect to :(
>>>
>>>
>>
>>I can't really intelligently comment on this one, since I don't know if
>>it's possible to rework that code to allow win32 spawn more than 1 proc :(
>>
>>
>
> It's easy to start >1 process -- just don't force the $one_process
> option into the start $cmd! The problem IIRC was trying to stop them
> later. I think if the user CTRL+C's the test suite then only the parent
> was stopped, leaving the child still running, but I need to look back
> over the archives to see exactly what the problem was.
sorry, I've meant to somehow do the whole thing, start > 1 and stop them
all of course.
>>what would be nice is to at least somehow abort the test suite, if there
>>is no server running.
>>
>
> That's an idea worth looking into sometime.
I'll put that on the todo list.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>
>>>No, it's something in the mp2 test setup. If I just start my installed
>>>Apache2/mp2 setup then I get two Apache.exe's as expected. I'll try to
>>>see what the difference is.
>>>
>>>
>>>
>>Got it. We made an exception for Win32 to always run in one-process
>>mode because otherwise we couldn't relaibly stop both the parent and
>>child processes. See the call to Win32::Process::Create() in
>>Apache::TestServer::start().
>>
>>It does have the undesirable side-effect that we have seen in this
>>thread, though, namely that if one test causes the single Apache.exe
>>process to exit for whatever reason then all subsequent tests will fail
>>since they now have no server to connect to :(
>>
>>
>
>I can't really intelligently comment on this one, since I don't know if
>it's possible to rework that code to allow win32 spawn more than 1 proc :(
>
>
It's easy to start >1 process -- just don't force the $one_process
option into the start $cmd! The problem IIRC was trying to stop them
later. I think if the user CTRL+C's the test suite then only the parent
was stopped, leaving the child still running, but I need to look back
over the archives to see exactly what the problem was.
>what would be nice is to at least somehow abort the test suite, if there
>is no server running.
>
That's an idea worth looking into sometime.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>No, it's something in the mp2 test setup. If I just start my installed
>>Apache2/mp2 setup then I get two Apache.exe's as expected. I'll try to
>>see what the difference is.
>>
>
> Got it. We made an exception for Win32 to always run in one-process
> mode because otherwise we couldn't relaibly stop both the parent and
> child processes. See the call to Win32::Process::Create() in
> Apache::TestServer::start().
>
> It does have the undesirable side-effect that we have seen in this
> thread, though, namely that if one test causes the single Apache.exe
> process to exit for whatever reason then all subsequent tests will fail
> since they now have no server to connect to :(
I can't really intelligently comment on this one, since I don't know if
it's possible to rework that code to allow win32 spawn more than 1 proc :(
what would be nice is to at least somehow abort the test suite, if there
is no server running.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>Stas Bekman wrote:
>
>
>
>>Steve Hay wrote:
>>
>>
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>>OK, that's better :) But doesn't Apache start a new process then?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>No -- we're only running one process (-D ONE_PROCESS) -- see
>>>>>Apache/TestServer.pm ;)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>You mean when debugging? Because normally we don't start one process.
>>>>
>>>>It's only the case if $self->{run}->{opts}->{'one-process'} is true.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Hmm. Where would that get set?
>>>
>>>
>>>
>>>
>>It's not. Unless you pass this option or you run coverage testing. on
>>worker mpm, we have two processes.
>>
>>
>>
>>
>>
>>>Both the full test suite and the bug reporting skeleton definitely only
>>>have one Apache.exe running in my Task Manager. However, I notice if I
>>>watch it carefully that a second Apache.exe appears very briefly and
>>>then disappears again.
>>>
>>>
>>>
>>>
>>a bug in Apache may be? May be check the winnt mpm source?
>>
>>
>>
>>
>No, it's something in the mp2 test setup. If I just start my installed
>Apache2/mp2 setup then I get two Apache.exe's as expected. I'll try to
>see what the difference is.
>
Got it. We made an exception for Win32 to always run in one-process
mode because otherwise we couldn't relaibly stop both the parent and
child processes. See the call to Win32::Process::Create() in
Apache::TestServer::start().
It does have the undesirable side-effect that we have seen in this
thread, though, namely that if one test causes the single Apache.exe
process to exit for whatever reason then all subsequent tests will fail
since they now have no server to connect to :(
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>[...]
>>
>>
>>
>>>>>The error_log only contains:
>>>>>
>>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
>>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
>>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
>>>>>[Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
>>>>>thread 0 starting.
>>>>>
>>>>>(and another 49 message like the last one, since ThreadsPerChild is 50)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>BTW, do we still need this hack? I thought it was supposed to be fixed in
>>>>2.0.50, no? (talking about the need to run as many threads as vhosts)
>>>>
>>>>
>>>>
>>>
>>>You're correct in that it is fixed in 2.0.50 (I just tried the test
>>>suite with ThreadsPerChild set at 2 and it worked OK still), but it was
>>>agreed at the time to leave the higher value in place for backwards
>>>compatibility. See:
>>>
>>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108505772101330&w=2
>>>
>>>
>>
>>Right, but A-T knows the apache version, so it could do the appropriate
>>decision when writing that file. I'm sure you'd appreciate to not see so
>>many useless logs in error_log and also it'll be faster, since many less
>>threads will be started, no?
>>
>>Is it possible that you could write that patch? That would be:
>>Apache-Test/lib/Apache/TestConfig.pm
>>
>>In fact I think it'd be cool to fix TestConfig.pm not to write irrelevant
>>config sections (e.g. prefork for win32, and vice versa).
>>
>>
>>
>>
>>>Having said that, that mail suggested adding a BACK_COMPAT_MARKER
>>>comment, which I don't see.
>>>
>>>
>>
>>Assuming that you work on that patch, you could definitely add it in the
>>right place.
>>
>
> I'm only around today, Thurs & Fri, then I'm off till January. It's
> unlikely I'll be able to look in these next three days, but I may get a
> chance over the holiday...
>
> I'd certainly like to have fewer threads started and less clutter in the
> conf file, so it is worth doing.
OK, I'll "todo" this and if no one beats you to it, you could do it in
January. ;0) Thanks Steve
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>[...]
>
>
>>>>The error_log only contains:
>>>>
>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
>>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
>>>>[Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
>>>>thread 0 starting.
>>>>
>>>>(and another 49 message like the last one, since ThreadsPerChild is 50)
>>>>
>>>>
>>>>
>>>>
>>>BTW, do we still need this hack? I thought it was supposed to be fixed in
>>>2.0.50, no? (talking about the need to run as many threads as vhosts)
>>>
>>>
>>>
>>You're correct in that it is fixed in 2.0.50 (I just tried the test
>>suite with ThreadsPerChild set at 2 and it worked OK still), but it was
>>agreed at the time to leave the higher value in place for backwards
>>compatibility. See:
>>
>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108505772101330&w=2
>>
>>
>
>Right, but A-T knows the apache version, so it could do the appropriate
>decision when writing that file. I'm sure you'd appreciate to not see so
>many useless logs in error_log and also it'll be faster, since many less
>threads will be started, no?
>
>Is it possible that you could write that patch? That would be:
>Apache-Test/lib/Apache/TestConfig.pm
>
>In fact I think it'd be cool to fix TestConfig.pm not to write irrelevant
>config sections (e.g. prefork for win32, and vice versa).
>
>
>
>>Having said that, that mail suggested adding a BACK_COMPAT_MARKER
>>comment, which I don't see.
>>
>>
>
>Assuming that you work on that patch, you could definitely add it in the
>right place.
>
I'm only around today, Thurs & Fri, then I'm off till January. It's
unlikely I'll be able to look in these next three days, but I may get a
chance over the holiday...
I'd certainly like to have fewer threads started and less clutter in the
conf file, so it is worth doing.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>>>The error_log only contains:
>>>
>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
>>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
>>>[Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
>>>thread 0 starting.
>>>
>>>(and another 49 message like the last one, since ThreadsPerChild is 50)
>>>
>>>
>>
>>BTW, do we still need this hack? I thought it was supposed to be fixed in
>>2.0.50, no? (talking about the need to run as many threads as vhosts)
>>
>
> You're correct in that it is fixed in 2.0.50 (I just tried the test
> suite with ThreadsPerChild set at 2 and it worked OK still), but it was
> agreed at the time to leave the higher value in place for backwards
> compatibility. See:
>
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108505772101330&w=2
Right, but A-T knows the apache version, so it could do the appropriate
decision when writing that file. I'm sure you'd appreciate to not see so
many useless logs in error_log and also it'll be faster, since many less
threads will be started, no?
Is it possible that you could write that patch? That would be:
Apache-Test/lib/Apache/TestConfig.pm
In fact I think it'd be cool to fix TestConfig.pm not to write irrelevant
config sections (e.g. prefork for win32, and vice versa).
> Having said that, that mail suggested adding a BACK_COMPAT_MARKER
> comment, which I don't see.
Assuming that you work on that patch, you could definitely add it in the
right place.
Thanks Steve.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>>>OK, that's better :) But doesn't Apache start a new process then?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>No -- we're only running one process (-D ONE_PROCESS) -- see
>>>>Apache/TestServer.pm ;)
>>>>
>>>>
>>>>
>>>>
>>>You mean when debugging? Because normally we don't start one process.
>>>
>>>It's only the case if $self->{run}->{opts}->{'one-process'} is true.
>>>
>>>
>>>
>>Hmm. Where would that get set?
>>
>>
>
>It's not. Unless you pass this option or you run coverage testing. on
>worker mpm, we have two processes.
>
>
>
>>Both the full test suite and the bug reporting skeleton definitely only
>>have one Apache.exe running in my Task Manager. However, I notice if I
>>watch it carefully that a second Apache.exe appears very briefly and
>>then disappears again.
>>
>>
>
>a bug in Apache may be? May be check the winnt mpm source?
>
>
No, it's something in the mp2 test setup. If I just start my installed
Apache2/mp2 setup then I get two Apache.exe's as expected. I'll try to
see what the difference is.
>
>
>>The error_log only contains:
>>
>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
>>[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
>>[Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
>>thread 0 starting.
>>
>>(and another 49 message like the last one, since ThreadsPerChild is 50)
>>
>>
>
>BTW, do we still need this hack? I thought it was supposed to be fixed in
>2.0.50, no? (talking about the need to run as many threads as vhosts)
>
You're correct in that it is fixed in 2.0.50 (I just tried the test
suite with ThreadsPerChild set at 2 and it worked OK still), but it was
agreed at the time to leave the higher value in place for backwards
compatibility. See:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108505772101330&w=2
Having said that, that mail suggested adding a BACK_COMPAT_MARKER
comment, which I don't see.
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>>>OK, that's better :) But doesn't Apache start a new process then?
>>>>
>>>>
>>>>
>>>
>>>No -- we're only running one process (-D ONE_PROCESS) -- see
>>>Apache/TestServer.pm ;)
>>>
>>>
>>
>>You mean when debugging? Because normally we don't start one process.
>>
>>It's only the case if $self->{run}->{opts}->{'one-process'} is true.
>>
>
> Hmm. Where would that get set?
It's not. Unless you pass this option or you run coverage testing. on
worker mpm, we have two processes.
> Both the full test suite and the bug reporting skeleton definitely only
> have one Apache.exe running in my Task Manager. However, I notice if I
> watch it carefully that a second Apache.exe appears very briefly and
> then disappears again.
a bug in Apache may be? May be check the winnt mpm source?
> The error_log only contains:
>
> [Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
> [Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
> [Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
> [Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
> thread 0 starting.
>
> (and another 49 message like the last one, since ThreadsPerChild is 50)
BTW, do we still need this hack? I thought it was supposed to be fixed in
2.0.50, no? (talking about the need to run as many threads as vhosts)
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>>>OK, that's better :) But doesn't Apache start a new process then?
>>>
>>>
>>>
>>No -- we're only running one process (-D ONE_PROCESS) -- see
>>Apache/TestServer.pm ;)
>>
>>
>
>You mean when debugging? Because normally we don't start one process.
>
>It's only the case if $self->{run}->{opts}->{'one-process'} is true.
>
Hmm. Where would that get set?
Both the full test suite and the bug reporting skeleton definitely only
have one Apache.exe running in my Task Manager. However, I notice if I
watch it carefully that a second Apache.exe appears very briefly and
then disappears again.
The error_log only contains:
[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Child process is running
[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Acquired the start mutex.
[Tue Dec 14 15:06:47 2004] [notice] Child 3844: Starting 50 worker threads.
[Tue Dec 14 15:06:47 2004] [debug] child.c(684): Child 3844: Worker
thread 0 starting.
(and another 49 message like the last one, since ThreadsPerChild is 50)
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
>>OK, that's better :) But doesn't Apache start a new process then?
>>
>
> No -- we're only running one process (-D ONE_PROCESS) -- see
> Apache/TestServer.pm ;)
You mean when debugging? Because normally we don't start one process.
It's only the case if $self->{run}->{opts}->{'one-process'} is true.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>
>>>>Oh yes! That kills the server itself! i.e. api.t now crashes the
>>>>server in the course of executing its test plan, and ithreads doesn't
>>>>even have a server to play with :(
>>>>
>>>>
>>>>
>>>>
>>>Crashes? CORE::exit() works fine here (happened to work fine?). I guess it
>>>should be a problem since it'll kill any other running threads.
>>>
>>>
>>>
>>Maybe "crash" was too strong a word. What I meant was that the
>>Apache.exe process exits, so now ithreads.t fails since there is no
>>server running for it to connect to.
>>
>>
>
>OK, that's better :) But doesn't Apache start a new process then?
>
No -- we're only running one process (-D ONE_PROCESS) -- see
Apache/TestServer.pm ;)
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>>Oh yes! That kills the server itself! i.e. api.t now crashes the
>>>server in the course of executing its test plan, and ithreads doesn't
>>>even have a server to play with :(
>>>
>>>
>>
>>Crashes? CORE::exit() works fine here (happened to work fine?). I guess it
>>should be a problem since it'll kill any other running threads.
>>
>
> Maybe "crash" was too strong a word. What I meant was that the
> Apache.exe process exits, so now ithreads.t fails since there is no
> server running for it to connect to.
OK, that's better :) But doesn't Apache start a new process then?
> As I understood it, this is exactly what overriding exit() was intended
> to prevent.
Exactly
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>Steve Hay wrote:
>>>
>>>
>>>
>>>
>>>
>>>>>>So the offending SV is an error message itself, caused by the exit in
>>>>>>these lines in Apache/Test.pm:
>>>>>>
>>>>>> # trying to emulate a dual variable (ala errno)
>>>>>> unless ($meets_condition) {
>>>>>> my $reason = join ', ',
>>>>>> @SkipReasons ? @SkipReasons : "no reason given";
>>>>>> print "1..0 # skipped: $reason\n";
>>>>>> @SkipReasons = (); # reset
>>>>>> exit; #XXX: Apache->exit
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>Any difference if you call CORE::exit() here?
>>>
>>>
>>>
>>Oh yes! That kills the server itself! i.e. api.t now crashes the
>>server in the course of executing its test plan, and ithreads doesn't
>>even have a server to play with :(
>>
>>
>
>Crashes? CORE::exit() works fine here (happened to work fine?). I guess it
>should be a problem since it'll kill any other running threads.
>
Maybe "crash" was too strong a word. What I meant was that the
Apache.exe process exits, so now ithreads.t fails since there is no
server running for it to connect to.
As I understood it, this is exactly what overriding exit() was intended
to prevent.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>>>So the offending SV is an error message itself, caused by the exit in
>>>>>these lines in Apache/Test.pm:
>>>>>
>>>>> # trying to emulate a dual variable (ala errno)
>>>>> unless ($meets_condition) {
>>>>> my $reason = join ', ',
>>>>> @SkipReasons ? @SkipReasons : "no reason given";
>>>>> print "1..0 # skipped: $reason\n";
>>>>> @SkipReasons = (); # reset
>>>>> exit; #XXX: Apache->exit
>>>>> }
>>>>>
>>>>>
>>
>>Any difference if you call CORE::exit() here?
>>
>
> Oh yes! That kills the server itself! i.e. api.t now crashes the
> server in the course of executing its test plan, and ithreads doesn't
> even have a server to play with :(
Crashes? CORE::exit() works fine here (happened to work fine?). I guess it
should be a problem since it'll kill any other running threads.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>>>So the offending SV is an error message itself, caused by the exit in
>>>>these lines in Apache/Test.pm:
>>>>
>>>> # trying to emulate a dual variable (ala errno)
>>>> unless ($meets_condition) {
>>>> my $reason = join ', ',
>>>> @SkipReasons ? @SkipReasons : "no reason given";
>>>> print "1..0 # skipped: $reason\n";
>>>> @SkipReasons = (); # reset
>>>> exit; #XXX: Apache->exit
>>>> }
>>>>
>>>>
>
>Any difference if you call CORE::exit() here?
>
Oh yes! That kills the server itself! i.e. api.t now crashes the
server in the course of executing its test plan, and ithreads doesn't
even have a server to play with :(
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>>So the offending SV is an error message itself, caused by the exit in
>>>these lines in Apache/Test.pm:
>>>
>>> # trying to emulate a dual variable (ala errno)
>>> unless ($meets_condition) {
>>> my $reason = join ', ',
>>> @SkipReasons ? @SkipReasons : "no reason given";
>>> print "1..0 # skipped: $reason\n";
>>> @SkipReasons = (); # reset
>>> exit; #XXX: Apache->exit
>>> }
Any difference if you call CORE::exit() here?
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>So the offending SV is an error message itself, caused by the exit in
>>these lines in Apache/Test.pm:
>>
>> # trying to emulate a dual variable (ala errno)
>> unless ($meets_condition) {
>> my $reason = join ', ',
>> @SkipReasons ? @SkipReasons : "no reason given";
>> print "1..0 # skipped: $reason\n";
>> @SkipReasons = (); # reset
>> exit; #XXX: Apache->exit
>> }
>>
>>In the test sequence "reload.t, api.t, itherads.t", the above "exit"
>>section is only reached by the api.t tests, because they skip on Win32.
>>So what happens for you if you artifically make the api.t tests skip on
>>your platform too? Can you reproduce the failure then?
>>
>>
>
>you mean re-enable t/perl/ithreads.t, skip api.t and run:
>
>% t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>
>just did that, and see no problem.
>
>
Yes. But how did you skip api.t? I meant edit
t/response/TestPerl/api.pm so that some condition is not met in the test
plan so that the chunk of code above gets run. The test plan is
expressed as:
plan $r, tests => 2,
need { "getppid() is not implemented on Win32"
=> !Apache::Build::WIN32(),
"getppid() is having problems with perl 5.6"
=> !($] < 5.008),
};
so change this to make it skip for you. (As opposed to just creating a
t/SKIP file, which wouldn't involve the "exit" code above.)
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> I moved the installing of the WARN handler to a .pl file PerlRequire'd
> from httpd.conf. I still get the above warning written to stderr.txt.
> Don't know what that proves.
Neither do I :(
>>Try adding sv_dump(sv) before SvREFCNT_dec() and hopefully it'll reveal
>>what sv it segfaults on? I think it tries to cleanup some modperl object
>>which didn't get cloned. in the call earlier:
>>
>>thread->interp = perl_clone(aTHX, CLONEf_KEEP_PTR_TABLE | CLONEf_CLONE_HOST);
>>
>
> sv_dump() just writes to SDTERR rather than warn()'ing, so I got rid of
> the WARN handler and put a crude hack into the ithreads handler() instead:
>
> close STDERR;
> open STDERR, '>C:\\Temp\\stderr.txt';
>
> I now get this in the stderr.txt file:
>
> SV = PV(0x31f64d0) at 0x31960b8
> REFCNT = 1
> FLAGS = (TEMP,POK,pPOK)
> PV = 0x31f7ed4 "ModPerl::Util::exit: (120000) exit was called at
> C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
> CUR = 98
> LEN = 99
> Attempt to free temp prematurely: SV 0x31960b8, Perl interpreter:
> 0x2b51784 at
> C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 56.
> Scalars leaked: 1
Aha! looks like we make some progress!
> So the offending SV is an error message itself, caused by the exit in
> these lines in Apache/Test.pm:
>
> # trying to emulate a dual variable (ala errno)
> unless ($meets_condition) {
> my $reason = join ', ',
> @SkipReasons ? @SkipReasons : "no reason given";
> print "1..0 # skipped: $reason\n";
> @SkipReasons = (); # reset
> exit; #XXX: Apache->exit
> }
>
> In the test sequence "reload.t, api.t, itherads.t", the above "exit"
> section is only reached by the api.t tests, because they skip on Win32.
> So what happens for you if you artifically make the api.t tests skip on
> your platform too? Can you reproduce the failure then?
you mean re-enable t/perl/ithreads.t, skip api.t and run:
% t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t
just did that, and see no problem.
but let me look at our exit code. (I wish I could reproduce it here)
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>The weird thing is that no warnings appear in the error_log. So I added
>>this instead of the use warnings line:
>>
>>$SIG{__WARN__} = sub {
>> open LOG, '>C:\\Temp\\stderr.txt';
>> print LOG @_;
>> close LOG;
>>};
>>
>>and now I get this written to that log:
>>
>>Attempt to free temp prematurely: SV 0x2fb241c, Perl interpreter:
>>0x2fa6014 at
>>C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 70.
>>
>>
>
>
>
>>Why didn't that warning make it to the error_log?
>>
>>
>
>probably because you added new code affecting memory alocations, which has
>again restored the problem. try putting this WARN handler in startup
>instead and may be you won't get any warnings now.
>
>
I moved the installing of the WARN handler to a .pl file PerlRequire'd
from httpd.conf. I still get the above warning written to stderr.txt.
Don't know what that proves.
>Try adding sv_dump(sv) before SvREFCNT_dec() and hopefully it'll reveal
>what sv it segfaults on? I think it tries to cleanup some modperl object
>which didn't get cloned. in the call earlier:
>
>thread->interp = perl_clone(aTHX, CLONEf_KEEP_PTR_TABLE | CLONEf_CLONE_HOST);
>
sv_dump() just writes to SDTERR rather than warn()'ing, so I got rid of
the WARN handler and put a crude hack into the ithreads handler() instead:
close STDERR;
open STDERR, '>C:\\Temp\\stderr.txt';
I now get this in the stderr.txt file:
SV = PV(0x31f64d0) at 0x31960b8
REFCNT = 1
FLAGS = (TEMP,POK,pPOK)
PV = 0x31f7ed4 "ModPerl::Util::exit: (120000) exit was called at
C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
CUR = 98
LEN = 99
Attempt to free temp prematurely: SV 0x31960b8, Perl interpreter:
0x2b51784 at
C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 56.
Scalars leaked: 1
SV = PV(0x30d6318) at 0x304d484
REFCNT = 1
FLAGS = (TEMP,POK,pPOK)
PV = 0x2cfd904 "ModPerl::Util::exit: (120000) exit was called at
C:/apache2/perl5/site/lib/Apache/Test.pm line 238"\0
CUR = 98
LEN = 99
Attempt to free temp prematurely: SV 0x304d484, Perl interpreter:
0x3186f0c at
C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 73.
Scalars leaked: 1
So the offending SV is an error message itself, caused by the exit in
these lines in Apache/Test.pm:
# trying to emulate a dual variable (ala errno)
unless ($meets_condition) {
my $reason = join ', ',
@SkipReasons ? @SkipReasons : "no reason given";
print "1..0 # skipped: $reason\n";
@SkipReasons = (); # reset
exit; #XXX: Apache->exit
}
In the test sequence "reload.t, api.t, itherads.t", the above "exit"
section is only reached by the api.t tests, because they skip on Win32.
So what happens for you if you artifically make the api.t tests skip on
your platform too? Can you reproduce the failure then?
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>Right, last night test_perl_ithreads moved to post_config_startup.pl. So
>>that note needs to be updated.
>
> (It still hasn't been.)
it has now. thanks for the reminder
> Anyway, I've made an interesting new discovery: the ithreads.t test
> crashes the server because ithreads.pm contains "use warnings FATAL =>
> 'all'". Simply commenting-out that line, the skeleton test now succeeds!
As suggested before I think this means nothing, but that the problem is
triggered by certain memory allocation patterns. I'm sure if you will
start adding some random code it will also succeed. I've seen this kind of
behavior before.
> The weird thing is that no warnings appear in the error_log. So I added
> this instead of the use warnings line:
>
> $SIG{__WARN__} = sub {
> open LOG, '>C:\\Temp\\stderr.txt';
> print LOG @_;
> close LOG;
> };
>
> and now I get this written to that log:
>
> Attempt to free temp prematurely: SV 0x2fb241c, Perl interpreter:
> 0x2fa6014 at
> C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 70.
> Why didn't that warning make it to the error_log?
probably because you added new code affecting memory alocations, which has
again restored the problem. try putting this WARN handler in startup
instead and may be you won't get any warnings now.
> Line 70 is the last line of this chunk:
>
> my $thr = threads->new(sub {
> my $tid = threads->self->tid;
> debug "2nd TID is $tid" if defined $tid;
> $counter_priv += $counter_priv for 1..10;
> {
> lock $counter_shar;
> $counter_shar += $counter_shar for 1..10;
> }
> });
>
> I see from the perl sources that the warning in question is only
> generated #ifdef DEBUGGING. Is your perl a DEBUGGING build? If not
> then that might be why you don't get this.
Absolutely. My perl is built like so:
./Configure -des -Dprefix=/home/stas/perl/5.8.6-ithread \
-Dusethreads -Doptimize='-g' -Duseshrplib -Dusedevel \
-Accflags="-DDEBUG_LEAKING_SCALARS"
> Here's the top (bottom?) of the call stack where that warning is emitted:
>
> Perl_sv_free(interpreter * 0x02fa6014, sv * 0x02fb241c) line 5362
> Perl_ithread_create(interpreter * 0x0270185c, sv * 0x00000000, char *
> 0x0154bd2c, sv * 0x02b4977c, sv * 0x02b49794) line 470 + 13 bytes
> XS_threads_new(interpreter * 0x0270185c, cv * 0x017308e8) line 681 + 36
> bytes
> Perl_pp_entersub(interpreter * 0x0270185c) line 2857 + 16 bytes
> Perl_runops_debug(interpreter * 0x0270185c) line 1442 + 13 bytes
> [...]
>
> Should the interpreter * passed to Perl_sv_free() be different to all
> the others in the calls above? Where does Perl_sv_free() even get its
> aTHX_ from? SvREFCNT_dec() doesn't pass it one.
it does:
#if defined(__GNUC__) && !defined(__STRICT_ANSI__) &&
!defined(PERL_GCC_PEDANTIC)
# define SvREFCNT_dec(sv) \
({ \
SV *_sv = (SV*)(sv); \
if (_sv) { \
if (SvREFCNT(_sv)) { \
if (--(SvREFCNT(_sv)) == 0) \
Perl_sv_free2(aTHX_ _sv); \
} else { \
sv_free(_sv); \
} \
} \
})
...
#define sv_free(a) Perl_sv_free(aTHX_ a)
Perl_sv_free() gets a different my_perl due to ithreads.xs:
dTHXa(thread->interp);
> There are some comments in perl (5.8.5)'s ext/threads/threads.xs, just
> above the SvREFCNT_dec() call (== Perl_sv_free() above) which might be
> of some interest?:
>
> /* The code below checks that anything living on
> the tmps stack and has been cloned (so it lives in the
> ptr_table) has a refcount higher than 0
>
> If the refcount is 0 it means that a something on the
> stack/context was holding a reference to it and
> since we init_stacks() in perl_clone that won't get
> cleaned and we will get a leaked scalar.
> The reason it was cloned was that it lived on the
> @_ stack.
>
> Example of this can be found in bugreport 15837
> where calls in the parameter list end up as a temp
>
> One could argue that this fix should be in perl_clone
> */
Try adding sv_dump(sv) before SvREFCNT_dec() and hopefully it'll reveal
what sv it segfaults on? I think it tries to cleanup some modperl object
which didn't get cloned. in the call earlier:
thread->interp = perl_clone(aTHX, CLONEf_KEEP_PTR_TABLE | CLONEf_CLONE_HOST);
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>>I've been walking through things in the debugger, and I've determined
>>that it crashes in ithreads.pm while trying to require threads.pm.
>>
>>I note that ithreads.pm contains this comment:
>>
>> # threads must have been preloaded at the server startup for this
>> # test (this is done at t/conf/modperl_extra.pl)
>> require threads;
>>
>>but the skeleton httpd.conf doesn't do this. I added a "PerlModule
>>threads" line to my extra.conf and tried again, but it didn't fix it :(
>>
>>The full mp2 test suite's actual modperl_extra.pl doesn't seem to
>>contain anything that loads threads either :-s Is something missing
>>here, or is that comment merely bogus?
>>
>>
>
>Right, last night test_perl_ithreads moved to post_config_startup.pl. So
>that note needs to be updated.
>
>
(It still hasn't been.)
>>[...] at this stage threads.dll has not been loaded by Apache.exe, so it
>>is obviously during the loading of that DLL that it crashes.
>>
>>
>
>So do you get any difference if you load it at the server startup, like
>mp2 test suite does?
>
No -- I said (above) adding "PerlModule threads" to extra.conf made no
difference.
I also tried PerlRequire()'ing a script that calls test_perl_ithreads()
to load threads.pm, but that makes no difference either.
Anyway, I've made an interesting new discovery: the ithreads.t test
crashes the server because ithreads.pm contains "use warnings FATAL =>
'all'". Simply commenting-out that line, the skeleton test now succeeds!
The weird thing is that no warnings appear in the error_log. So I added
this instead of the use warnings line:
$SIG{__WARN__} = sub {
open LOG, '>C:\\Temp\\stderr.txt';
print LOG @_;
close LOG;
};
and now I get this written to that log:
Attempt to free temp prematurely: SV 0x2fb241c, Perl interpreter:
0x2fa6014 at
C:/Temp/bug-reporting-skeleton-mp2/t/response/TestPerl/ithreads.pm line 70.
Why didn't that warning make it to the error_log?
Line 70 is the last line of this chunk:
my $thr = threads->new(sub {
my $tid = threads->self->tid;
debug "2nd TID is $tid" if defined $tid;
$counter_priv += $counter_priv for 1..10;
{
lock $counter_shar;
$counter_shar += $counter_shar for 1..10;
}
});
I see from the perl sources that the warning in question is only
generated #ifdef DEBUGGING. Is your perl a DEBUGGING build? If not
then that might be why you don't get this.
Here's the top (bottom?) of the call stack where that warning is emitted:
Perl_sv_free(interpreter * 0x02fa6014, sv * 0x02fb241c) line 5362
Perl_ithread_create(interpreter * 0x0270185c, sv * 0x00000000, char *
0x0154bd2c, sv * 0x02b4977c, sv * 0x02b49794) line 470 + 13 bytes
XS_threads_new(interpreter * 0x0270185c, cv * 0x017308e8) line 681 + 36
bytes
Perl_pp_entersub(interpreter * 0x0270185c) line 2857 + 16 bytes
Perl_runops_debug(interpreter * 0x0270185c) line 1442 + 13 bytes
[...]
Should the interpreter * passed to Perl_sv_free() be different to all
the others in the calls above? Where does Perl_sv_free() even get its
aTHX_ from? SvREFCNT_dec() doesn't pass it one.
There are some comments in perl (5.8.5)'s ext/threads/threads.xs, just
above the SvREFCNT_dec() call (== Perl_sv_free() above) which might be
of some interest?:
/* The code below checks that anything living on
the tmps stack and has been cloned (so it lives in the
ptr_table) has a refcount higher than 0
If the refcount is 0 it means that a something on the
stack/context was holding a reference to it and
since we init_stacks() in perl_clone that won't get
cleaned and we will get a leaked scalar.
The reason it was cloned was that it lived on the
@_ stack.
Example of this can be found in bugreport 15837
where calls in the parameter list end up as a temp
One could argue that this fix should be in perl_clone
*/
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
> OK. New tarball attached for future ease of reference. Still fails as
> before for me.
Excellent. Now I can run it out of box. Thanks.
>>As expected, I get no problem with this setup. :(
>>
>
> I've been walking through things in the debugger, and I've determined
> that it crashes in ithreads.pm while trying to require threads.pm.
>
> I note that ithreads.pm contains this comment:
>
> # threads must have been preloaded at the server startup for this
> # test (this is done at t/conf/modperl_extra.pl)
> require threads;
>
> but the skeleton httpd.conf doesn't do this. I added a "PerlModule
> threads" line to my extra.conf and tried again, but it didn't fix it :(
>
> The full mp2 test suite's actual modperl_extra.pl doesn't seem to
> contain anything that loads threads either :-s Is something missing
> here, or is that comment merely bogus?
Right, last night test_perl_ithreads moved to post_config_startup.pl. So
that note needs to be updated.
> Some more detail on where it crashes:
>
> A while before the crash I have this call stack:
>
> Perl_yyparse(interpreter * 0x021ce0f4) line 380
> S_doeval(interpreter * 0x021ce0f4, int 0, op * * 0x00000000, cv *
> 0x00000000, unsigned long 11501) line 2817 + 9 bytes
> Perl_pp_require(interpreter * 0x021ce0f4) line 3314 + 102 bytes
> modperl_pp_require(interpreter * 0x021ce0f4) line 69 + 10 bytes
> Perl_runops_debug(interpreter * 0x021ce0f4) line 1442 + 13 bytes
> S_call_body(interpreter * 0x021ce0f4, op * 0x04a3fd40, int 0) line 2288
> + 13 bytes
> Perl_call_sv(interpreter * 0x021ce0f4, sv * 0x02b240e8, long 4) line
> 2206 + 15 bytes
> modperl_callback(interpreter * 0x021ce0f4, modperl_handler_t *
> 0x008fa698, apr_pool_t * 0x008eb3f8, request_rec * 0x008eb430,
> server_rec * 0x0029ce20, av * 0x02ad69ec) line 102 + 17 bytes
> modperl_callback_run_handlers(int 6, int 4, request_rec * 0x008eb430,
> conn_rec * 0x00000000, server_rec * 0x0029ce20, apr_pool_t * 0x00000000,
> apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 263 + 35 bytes
> modperl_callback_per_dir(int 6, request_rec * 0x008eb430, int 1) line
> 353 + 34 bytes
> modperl_response_handler_run(request_rec * 0x008eb430, int 1) line 963 +
> 13 bytes
> modperl_response_handler(request_rec * 0x008eb430) line 1003 + 11 bytes
> ap_run_handler(request_rec * 0x008eb430) line 152 + 78 bytes
> ap_invoke_handler(request_rec * 0x008eb430) line 358 + 9 bytes
> ap_process_request(request_rec * 0x008eb430) line 246 + 9 bytes
> ap_process_http_connection(conn_rec * 0x008e73f8) line 250 + 9 bytes
> ap_run_process_connection(conn_rec * 0x008e73f8) line 42 + 78 bytes
> ap_process_connection(conn_rec * 0x008e73f8, void * 0x008e7328) line 177
> worker_main(long 1) line 720
> _threadstartex(void * 0x0029da38) line 212 + 13 bytes
> KERNEL32! 77e7d33b()
>
> where "name" in the Perl_pp_require() is "threads.pm". Stepping ouf of
> there back to Perl_runops_debug() I can then go back into
> Perl_pp_require() twice more: once for Exporter.pm, then for DynaLoader.pm.
>
> After that, it's a long trawl through the various ops (?) in the main
> loop within Perl_runops_debug(). Shortly before the crash we go into
> pp_method_named(); going into S_method_common() I see that the "name" is
> "bootstrap". We then have these other ops:
>
> pp_entersub
> pp_nextstate
> pp_pushmark
> pp_gv
> pp_rv2av
> pp_pushmark
> pp_gv
> pp_rv2av
> pp_aassign
> pp_nextstate
> pp_pushmark
> pp_aelemfast
> pp_pushmark
> pp_gvsv
> pp_aassign
> pp_nextstate
> pp_pushmark
> pp_gv
> pp_rv2av
> pp_gvsv
>
> It crashes within that last call, but I didn't catch where :( I'll try
> again next week.
>
> Anyway, you can see that threads.pm contains:
>
> require Exporter;
> require DynaLoader;
> [...]
> bootstrap threads $VERSION;
>
> and at this stage threads.dll has not been loaded by Apache.exe, so it
> is obviously during the loading of that DLL that it crashes.
So do you get any difference if you load it at the server startup, like
mp2 test suite does?
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Attached (hopefully) is a new tarball with a (simplified)
>>HOW_TO_REPRODUCE file, and hash_attack.pm moved to t/lib/
>>
>>
>
>Your t/conf/extra.conf.in has hardcoded path and you miss PerlModule
>Apache2. so it should be:
>
>PerlSwitches -I@ServerRoot@
>PerlSwitches -I@ServerRoot@/response
>PerlSwitches -I@ServerRoot@/lib
>PerlModule Apache2
>PerlModule Apache::RequestRec
>PerlModule Apache::TestHandler
>PerlModule APR::Table
>PerlModule TestPerl::hash_attack
>
>
OK. New tarball attached for future ease of reference. Still fails as
before for me.
>As expected, I get no problem with this setup. :(
>
I've been walking through things in the debugger, and I've determined
that it crashes in ithreads.pm while trying to require threads.pm.
I note that ithreads.pm contains this comment:
# threads must have been preloaded at the server startup for this
# test (this is done at t/conf/modperl_extra.pl)
require threads;
but the skeleton httpd.conf doesn't do this. I added a "PerlModule
threads" line to my extra.conf and tried again, but it didn't fix it :(
The full mp2 test suite's actual modperl_extra.pl doesn't seem to
contain anything that loads threads either :-s Is something missing
here, or is that comment merely bogus?
Some more detail on where it crashes:
A while before the crash I have this call stack:
Perl_yyparse(interpreter * 0x021ce0f4) line 380
S_doeval(interpreter * 0x021ce0f4, int 0, op * * 0x00000000, cv *
0x00000000, unsigned long 11501) line 2817 + 9 bytes
Perl_pp_require(interpreter * 0x021ce0f4) line 3314 + 102 bytes
modperl_pp_require(interpreter * 0x021ce0f4) line 69 + 10 bytes
Perl_runops_debug(interpreter * 0x021ce0f4) line 1442 + 13 bytes
S_call_body(interpreter * 0x021ce0f4, op * 0x04a3fd40, int 0) line 2288
+ 13 bytes
Perl_call_sv(interpreter * 0x021ce0f4, sv * 0x02b240e8, long 4) line
2206 + 15 bytes
modperl_callback(interpreter * 0x021ce0f4, modperl_handler_t *
0x008fa698, apr_pool_t * 0x008eb3f8, request_rec * 0x008eb430,
server_rec * 0x0029ce20, av * 0x02ad69ec) line 102 + 17 bytes
modperl_callback_run_handlers(int 6, int 4, request_rec * 0x008eb430,
conn_rec * 0x00000000, server_rec * 0x0029ce20, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 1) line 263 + 35 bytes
modperl_callback_per_dir(int 6, request_rec * 0x008eb430, int 1) line
353 + 34 bytes
modperl_response_handler_run(request_rec * 0x008eb430, int 1) line 963 +
13 bytes
modperl_response_handler(request_rec * 0x008eb430) line 1003 + 11 bytes
ap_run_handler(request_rec * 0x008eb430) line 152 + 78 bytes
ap_invoke_handler(request_rec * 0x008eb430) line 358 + 9 bytes
ap_process_request(request_rec * 0x008eb430) line 246 + 9 bytes
ap_process_http_connection(conn_rec * 0x008e73f8) line 250 + 9 bytes
ap_run_process_connection(conn_rec * 0x008e73f8) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x008e73f8, void * 0x008e7328) line 177
worker_main(long 1) line 720
_threadstartex(void * 0x0029da38) line 212 + 13 bytes
KERNEL32! 77e7d33b()
where "name" in the Perl_pp_require() is "threads.pm". Stepping ouf of
there back to Perl_runops_debug() I can then go back into
Perl_pp_require() twice more: once for Exporter.pm, then for DynaLoader.pm.
After that, it's a long trawl through the various ops (?) in the main
loop within Perl_runops_debug(). Shortly before the crash we go into
pp_method_named(); going into S_method_common() I see that the "name" is
"bootstrap". We then have these other ops:
pp_entersub
pp_nextstate
pp_pushmark
pp_gv
pp_rv2av
pp_pushmark
pp_gv
pp_rv2av
pp_aassign
pp_nextstate
pp_pushmark
pp_aelemfast
pp_pushmark
pp_gvsv
pp_aassign
pp_nextstate
pp_pushmark
pp_gv
pp_rv2av
pp_gvsv
It crashes within that last call, but I didn't catch where :( I'll try
again next week.
Anyway, you can see that threads.pm contains:
require Exporter;
require DynaLoader;
[...]
bootstrap threads $VERSION;
and at this stage threads.dll has not been loaded by Apache.exe, so it
is obviously during the loading of that DLL that it crashes.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Surely which tests get run should depend on which tests exist (*.t
>>>files), rather than which t/response/*.pm files exist?
>>>
>>>
>>
>>It's a feature. *.t is autogenerated if t/response/*/*.pm is found. So if
>>you want to create some module which is *not* a response handler, put it
>>in t/lib or lib instead.
>>
>>
>
> Ah. I didn't realise that.
>
>
>>>Attached is a new test skeleton. I am able to reproduce the failure
>>>using the skeleton in the following way (the usual "perl Makefile.PL /
>>>make / make test" sequence won't work because of the hash_attack problem
>>>described above):
>>>
>>>1. Extract tarball
>>>
>>>2. Run "perl Makefile.PL -apxs C:\apache2\bin\apxs.bat" [or wherever
>>>your apxs is] to generate a t/TEST
>>>
>>>3. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
>>>to explicitly run the tests that actually exist ;) This succeeds at
>>>this stage -- all tests OK.
>>>
>>>4. Edit t/conf/httpd.conf as follows:
>>>
>>>4a. Change the lines that look something like this:
>>>
>>><IfModule mod_perl.c>
>>> PerlRequire C:\Temp\bug-reporting-skeleton-mp2\t\conf\modperl_startup.pl
>>></IfModule>
>>>
>>>to something like this instead:
>>>
>>>PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\response
>>>PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\lib
>>>PerlModule Apache2
>>>
>>>4b. Insert the line:
>>>
>>>PerlModule TestPerl::hash_attack
>>>
>>>just before the lines:
>>>
>>><Location /TestPerl__hash_attack>
>>> SetHandler modperl
>>> PerlResponseHandler TestPerl::hash_attack
>>></Location>
>>>
>>>5. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
>>>again. This time, the ithreads.t test crashes the server.
>>>
>>>
>>>
>>
>>Any chance you can make the failing tarball, which already includes all
>>the above?
>>
>>
>
> Do you mean a tarball which contains those instructions or a tarball of
> my skeleton tree in which those instructions have already been carried out?
>
> I assume you mean the former, since latter wouldn't be very useful.
> Attached (hopefully) is a new tarball with a (simplified)
> HOW_TO_REPRODUCE file, and hash_attack.pm moved to t/lib/
Your t/conf/extra.conf.in has hardcoded path and you miss PerlModule
Apache2. so it should be:
PerlSwitches -I@ServerRoot@
PerlSwitches -I@ServerRoot@/response
PerlSwitches -I@ServerRoot@/lib
PerlModule Apache2
PerlModule Apache::RequestRec
PerlModule Apache::TestHandler
PerlModule APR::Table
PerlModule TestPerl::hash_attack
As expected, I get no problem with this setup. :(
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Surely which tests get run should depend on which tests exist (*.t
>>files), rather than which t/response/*.pm files exist?
>>
>>
>
>It's a feature. *.t is autogenerated if t/response/*/*.pm is found. So if
>you want to create some module which is *not* a response handler, put it
>in t/lib or lib instead.
>
>
Ah. I didn't realise that.
>>Attached is a new test skeleton. I am able to reproduce the failure
>>using the skeleton in the following way (the usual "perl Makefile.PL /
>>make / make test" sequence won't work because of the hash_attack problem
>>described above):
>>
>>1. Extract tarball
>>
>>2. Run "perl Makefile.PL -apxs C:\apache2\bin\apxs.bat" [or wherever
>>your apxs is] to generate a t/TEST
>>
>>3. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
>>to explicitly run the tests that actually exist ;) This succeeds at
>>this stage -- all tests OK.
>>
>>4. Edit t/conf/httpd.conf as follows:
>>
>>4a. Change the lines that look something like this:
>>
>><IfModule mod_perl.c>
>> PerlRequire C:\Temp\bug-reporting-skeleton-mp2\t\conf\modperl_startup.pl
>></IfModule>
>>
>>to something like this instead:
>>
>>PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\response
>>PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\lib
>>PerlModule Apache2
>>
>>4b. Insert the line:
>>
>>PerlModule TestPerl::hash_attack
>>
>>just before the lines:
>>
>><Location /TestPerl__hash_attack>
>> SetHandler modperl
>> PerlResponseHandler TestPerl::hash_attack
>></Location>
>>
>>5. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
>>again. This time, the ithreads.t test crashes the server.
>>
>>
>>
>
>Any chance you can make the failing tarball, which already includes all
>the above?
>
>
Do you mean a tarball which contains those instructions or a tarball of
my skeleton tree in which those instructions have already been carried out?
I assume you mean the former, since latter wouldn't be very useful.
Attached (hopefully) is a new tarball with a (simplified)
HOW_TO_REPRODUCE file, and hash_attack.pm moved to t/lib/
>
>
>>As before, the crash doesn't happen without that hash_attack line.
>>
>>I don't know why replacing modperl_startup.pl with PerlSwitches is
>>necessary to reproduce the crash here. (Clearly it wasn't necessary in
>>the main mp2 test suite, or I'd never have found the crash to start
>>with!) My modperl_startup.pl contains just:
>>
>>BEGIN {
>> use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
>> for my $file (qw(modperl_inc.pl modperl_extra.pl)) {
>> eval { require "conf/$file" } or
>> die if grep { -e "$_/conf/$file" } @INC;
>> }
>>}
>>
>>There is no modperl_extra.pl, and modperl_inc.pl only contains:
>>
>>use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\response';
>>use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\lib';
>>use Apache2;
>>
>>so I would have thought the change described above achieves nothing.
>>What's the difference?
>>
>>
>
>I think the only difference is that you don't add this path to @INC:
>
> use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
>
>
Oh yeah - I didn't see that! Adding it to the list of PerlSwitches
makes no difference, though.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>
>>Grep the test suite code for cleanup_register. could also check the
>>tracing (but grep is probably easier)
>>
>>
>
> Grepping shows that only these files mention "cleanup_register":
>
> conf/post_config_startup.pl
> hooks/TestHooks/cleanup2.pm
> lib/TestAPIlib/pool.pm
> response/TestAPI/request_util.pm
> response/TestAPI/server_util.pm
> response/TestAPR/pool.pm
>
> My minimal conf doesn't mention any of those, so I guess we're OK there.
I suppose so.
>>The bug reporting skeleton is just as good as the mp2 test suite. The only
>>difference is that with mp2 test suite you start with a lot and then you
>>cut down. and withe the skeleton you start with nothing and add things up.
>>Of course if you prefer to work with the test suite that is perfectly fine.
>>
>>Those seemingly unrelated code chunks/directives can in fact be very
>>related to crash.
>>
>
> Absolutely. That's why I need to have a level of control over them
> which the skeleton doesn't afford me.
It gives you exactly the same level of control as the modperl test suite.
No more and no less.
>>Most likely we need to add CLONE function to all modules
>>that return objects. I guess that's a very possible reason for the
>>ithreads test crash. Notice that ithreads2 doesn't crash, since it runs
>>against a different perl pool with very little code loaded.
>>
>>
>
> That gives me a lovely warm feeling. (Down the inside of my leg.)
Well, actually it's not exactly true. I think only to those packages that
define DESTROY function (the CLONE is needed so that DESTROY won't try to
free the same C struct more than once). And APR::Pool is one of those
candidates needing CLONE. It'll become even more crucial when we create
the dependencies on pool objects in methods that take the pool object.
> Well, the output of the skeleton thing is well over 3 times the size of
> my minimal setup, which I just felt was a step backwards. Maybe the
> extra stuff doesn't matter, as you say.
It doesn't.
> What *is* a pain, though, is that I noted previously that if I delete
> the "PerlModule TestPerl::hash_attack" line from my minimal conf then it
> suddenly works (even though has_attack.pm just contains "1;"). My
> original skeleton didn't include hash_attack, so it occurred to me that
> that maybe why it worked. But when I dropped a suitable hash_attack.pm
> in place, I now find that the generated .conf file contains:
>
> <Location /TestPerl__hash_attack>
> SetHandler modperl
> PerlResponseHandler TestPerl::hash_attack
> </Location>
>
> and it tries to run a t/perl/hash_attack.t test, even though not such
> file exists! This causes the server to crash:
>
> t\perl\hash_attack....request has failed (the response code was: 500)
> see t/logs/error_log for more details
> t\perl\hash_attack....dubious
> Test returned status 9 (wstat 2304, 0x900)
>
> so it never even gets to the ithreads test!
>
> Surely which tests get run should depend on which tests exist (*.t
> files), rather than which t/response/*.pm files exist?
It's a feature. *.t is autogenerated if t/response/*/*.pm is found. So if
you want to create some module which is *not* a response handler, put it
in t/lib or lib instead.
>>The good thing is that we can pass the tarball around w/o having
>>a problem with hardcoded path, which your originally submitted config file
>>had, which is certainly not runnable on my machine without painful manual
>>tweaks.
>>
>>
>
> There's only 10 Windows paths in it. I don't see that anything else
> needs changing.
It's still a manual error-work prone to do. And it will be lost every time
'make test' is run. Not fun.
>>If you want to keep your config file in this tarball to a minimum create:
>>
>> t/conf/steve.conf.in
>>
>>or
>>
>> t/conf/steve.last.conf.in
>>
>>depending on when do you do you want it to be included. and put all the
>>stuff there. It will be automatically included on t/TEST -conf.
>>
>
> That just seems to include my stuff *as well as* all the stuff that it's
> already generated itself. So now I have an even larger conf!
But it keeps your stuff in your file.
> I am singularly unable to persuade the test skeleton to generate a
> minimal (or even slightly larger) conf file with the "PerlModule
> TestPerl::hash_attack" in the appropriate place without it also trying
> to run some tests that don't exist :(
See above.
> Attached is a new test skeleton. I am able to reproduce the failure
> using the skeleton in the following way (the usual "perl Makefile.PL /
> make / make test" sequence won't work because of the hash_attack problem
> described above):
>
> 1. Extract tarball
>
> 2. Run "perl Makefile.PL -apxs C:\apache2\bin\apxs.bat" [or wherever
> your apxs is] to generate a t/TEST
>
> 3. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
> to explicitly run the tests that actually exist ;) This succeeds at
> this stage -- all tests OK.
>
> 4. Edit t/conf/httpd.conf as follows:
>
> 4a. Change the lines that look something like this:
>
> <IfModule mod_perl.c>
> PerlRequire C:\Temp\bug-reporting-skeleton-mp2\t\conf\modperl_startup.pl
> </IfModule>
>
> to something like this instead:
>
> PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\response
> PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\lib
> PerlModule Apache2
>
> 4b. Insert the line:
>
> PerlModule TestPerl::hash_attack
>
> just before the lines:
>
> <Location /TestPerl__hash_attack>
> SetHandler modperl
> PerlResponseHandler TestPerl::hash_attack
> </Location>
>
> 5. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
> again. This time, the ithreads.t test crashes the server.
>
Any chance you can make the failing tarball, which already includes all
the above?
> As before, the crash doesn't happen without that hash_attack line.
>
> I don't know why replacing modperl_startup.pl with PerlSwitches is
> necessary to reproduce the crash here. (Clearly it wasn't necessary in
> the main mp2 test suite, or I'd never have found the crash to start
> with!) My modperl_startup.pl contains just:
>
> BEGIN {
> use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
> for my $file (qw(modperl_inc.pl modperl_extra.pl)) {
> eval { require "conf/$file" } or
> die if grep { -e "$_/conf/$file" } @INC;
> }
> }
>
> There is no modperl_extra.pl, and modperl_inc.pl only contains:
>
> use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\response';
> use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\lib';
> use Apache2;
>
> so I would have thought the change described above achieves nothing.
> What's the difference?
I think the only difference is that you don't add this path to @INC:
use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
Otherwise PerlSwitches add path to @INC at the interpreter startup, use
lib adds those at run time. And also use libs loads a few extra modules.
When you talk about crashes it's quite possible that asking for more or
less memory will affect the crash, since may be that exact extra
allocation has caused an access violation. And if that's the cause, it's
going to be very hard to reproduce it on a different OS where the memory
allocation and access processes are very different.
In any case I want us to have a tarball, which fails for you and we can
for example give it to Randy or Gisle and see if crashes for him. And then
if we try various fixes we can again test whether it still fails. Note
that the ever evolving mp2 test suite may just stop crashing for you when
new tests are added. That's why I want to freeze that moment.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>Attached is a new test skeleton.
>
Damn. Damn. Damn.
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>>>In your minimum setup try to get rid of most of the parts in:
>>>
>>>C:\Temp\mod_perl-2.0\t\conf\modperl_extra.pl
>>>
>>>and make sure that no pool cleanup is registered and see if you still get
>>>a crash.
>>>
>>>
>>>
>>>
>>I'll look into this. How do I tell if any pool cleanup is registered,
>>though?
>>
>>
>
>Grep the test suite code for cleanup_register. could also check the
>tracing (but grep is probably easier)
>
>
Grepping shows that only these files mention "cleanup_register":
conf/post_config_startup.pl
hooks/TestHooks/cleanup2.pm
lib/TestAPIlib/pool.pm
response/TestAPI/request_util.pm
response/TestAPI/server_util.pm
response/TestAPR/pool.pm
My minimal conf doesn't mention any of those, so I guess we're OK there.
>
>
>>>Again, you will probably make a much nicer progress using
>>>http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
>>>
>>>
>>>
>>Sadly not. Attached is the .tar.gz that I made, but it passes all tests
>>successfully!
>>
>>
>
>Excellent :) So you need to find what's the difference between the two.
>
>
A lot!...
>
>
>>As noted before, the minimal configuration that I've come up with myself
>>(i.e. not involving the bug reporting skeleton) seems to be sensitive to
>>the inclusion or otherwise of seemingly unrelated code / directives.
>>The slightest deviation from the conf that I last posted can result in
>>the tests suddenly working, hence the bug reporting skeleton is no good
>>here since it doesn't give me anything like the control over the
>>httpd.conf that I seem to need.
>>
>>
>
>The bug reporting skeleton is just as good as the mp2 test suite. The only
>difference is that with mp2 test suite you start with a lot and then you
>cut down. and withe the skeleton you start with nothing and add things up.
>Of course if you prefer to work with the test suite that is perfectly fine.
>
>Those seemingly unrelated code chunks/directives can in fact be very
>related to crash.
>
Absolutely. That's why I need to have a level of control over them
which the skeleton doesn't afford me.
>Most likely we need to add CLONE function to all modules
>that return objects. I guess that's a very possible reason for the
>ithreads test crash. Notice that ithreads2 doesn't crash, since it runs
>against a different perl pool with very little code loaded.
>
>
That gives me a lovely warm feeling. (Down the inside of my leg.)
>
>
>>When I run "nmake test" with the attached tarball it generates a huge
>>new httpd.conf, full of the crap that I've spent ages slowly whittling
>>away from it :(
>>
>>
>
>What do you mean? I can't see any crap in it. What things you didn't want
>to show up (do you mean the prefork and other unrelated config chunks?)
>just disregard those, since they certainly have nothing to do with the
>problem.
>
Well, the output of the skeleton thing is well over 3 times the size of
my minimal setup, which I just felt was a step backwards. Maybe the
extra stuff doesn't matter, as you say.
What *is* a pain, though, is that I noted previously that if I delete
the "PerlModule TestPerl::hash_attack" line from my minimal conf then it
suddenly works (even though has_attack.pm just contains "1;"). My
original skeleton didn't include hash_attack, so it occurred to me that
that maybe why it worked. But when I dropped a suitable hash_attack.pm
in place, I now find that the generated .conf file contains:
<Location /TestPerl__hash_attack>
SetHandler modperl
PerlResponseHandler TestPerl::hash_attack
</Location>
and it tries to run a t/perl/hash_attack.t test, even though not such
file exists! This causes the server to crash:
t\perl\hash_attack....request has failed (the response code was: 500)
see t/logs/error_log for more details
t\perl\hash_attack....dubious
Test returned status 9 (wstat 2304, 0x900)
so it never even gets to the ithreads test!
Surely which tests get run should depend on which tests exist (*.t
files), rather than which t/response/*.pm files exist?
>The good thing is that we can pass the tarball around w/o having
>a problem with hardcoded path, which your originally submitted config file
>had, which is certainly not runnable on my machine without painful manual
>tweaks.
>
>
There's only 10 Windows paths in it. I don't see that anything else
needs changing.
>If you want to keep your config file in this tarball to a minimum create:
>
> t/conf/steve.conf.in
>
>or
>
> t/conf/steve.last.conf.in
>
>depending on when do you do you want it to be included. and put all the
>stuff there. It will be automatically included on t/TEST -conf.
>
That just seems to include my stuff *as well as* all the stuff that it's
already generated itself. So now I have an even larger conf!
I am singularly unable to persuade the test skeleton to generate a
minimal (or even slightly larger) conf file with the "PerlModule
TestPerl::hash_attack" in the appropriate place without it also trying
to run some tests that don't exist :(
Attached is a new test skeleton. I am able to reproduce the failure
using the skeleton in the following way (the usual "perl Makefile.PL /
make / make test" sequence won't work because of the hash_attack problem
described above):
1. Extract tarball
2. Run "perl Makefile.PL -apxs C:\apache2\bin\apxs.bat" [or wherever
your apxs is] to generate a t/TEST
3. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
to explicitly run the tests that actually exist ;) This succeeds at
this stage -- all tests OK.
4. Edit t/conf/httpd.conf as follows:
4a. Change the lines that look something like this:
<IfModule mod_perl.c>
PerlRequire C:\Temp\bug-reporting-skeleton-mp2\t\conf\modperl_startup.pl
</IfModule>
to something like this instead:
PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\response
PerlSwitches -IC:\Temp\bug-reporting-skeleton-mp2\t\lib
PerlModule Apache2
4b. Insert the line:
PerlModule TestPerl::hash_attack
just before the lines:
<Location /TestPerl__hash_attack>
SetHandler modperl
PerlResponseHandler TestPerl::hash_attack
</Location>
5. Run "perl t/TEST t/modules/reload.t t/perl/api.t t/perl/ithreads.t"
again. This time, the ithreads.t test crashes the server.
As before, the crash doesn't happen without that hash_attack line.
I don't know why replacing modperl_startup.pl with PerlSwitches is
necessary to reproduce the crash here. (Clearly it wasn't necessary in
the main mp2 test suite, or I'd never have found the crash to start
with!) My modperl_startup.pl contains just:
BEGIN {
use lib 'C:/Temp/bug-reporting-skeleton-mp2/t';
for my $file (qw(modperl_inc.pl modperl_extra.pl)) {
eval { require "conf/$file" } or
die if grep { -e "$_/conf/$file" } @INC;
}
}
There is no modperl_extra.pl, and modperl_inc.pl only contains:
use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\response';
use lib 'C:\Temp\bug-reporting-skeleton-mp2\t\lib';
use Apache2;
so I would have thought the change described above achieves nothing.
What's the difference?
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>I have some ideas. I wonder if those notes from xs/APR/Pool/APR__Pool.h
>>could be relevant to this problem:
>>
>>/* XXX: this implementation has a problem with perl ithreads. if a
>> * custom pool is allocated, and then a thread is spawned we now have
>> * two copies of the pool object, each living in a different perl
>> * interpreter, both pointing to the same memory address of the apr
>> * pool.
>> *
>> * need to write a CLONE class method could properly clone the
>> * thread's copied object, but it's tricky:
>> * - it needs to call parent_get() on the copied object and allocate a
>> * new pool from that parent's pool
>> * - it needs to reinstall any registered cleanup callbacks (can we do
>> * that?) may be we can skip those?
>> */
>>
>>In your minimum setup try to get rid of most of the parts in:
>>
>>C:\Temp\mod_perl-2.0\t\conf\modperl_extra.pl
>>
>>and make sure that no pool cleanup is registered and see if you still get
>>a crash.
>>
>>
>
> I'll look into this. How do I tell if any pool cleanup is registered,
> though?
Grep the test suite code for cleanup_register. could also check the
tracing (but grep is probably easier)
>>Again, you will probably make a much nicer progress using
>>http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
>>
>
> Sadly not. Attached is the .tar.gz that I made, but it passes all tests
> successfully!
Excellent :) So you need to find what's the difference between the two.
> As noted before, the minimal configuration that I've come up with myself
> (i.e. not involving the bug reporting skeleton) seems to be sensitive to
> the inclusion or otherwise of seemingly unrelated code / directives.
> The slightest deviation from the conf that I last posted can result in
> the tests suddenly working, hence the bug reporting skeleton is no good
> here since it doesn't give me anything like the control over the
> httpd.conf that I seem to need.
The bug reporting skeleton is just as good as the mp2 test suite. The only
difference is that with mp2 test suite you start with a lot and then you
cut down. and withe the skeleton you start with nothing and add things up.
Of course if you prefer to work with the test suite that is perfectly fine.
Those seemingly unrelated code chunks/directives can in fact be very
related to crash. Most likely we need to add CLONE function to all modules
that return objects. I guess that's a very possible reason for the
ithreads test crash. Notice that ithreads2 doesn't crash, since it runs
against a different perl pool with very little code loaded.
> When I run "nmake test" with the attached tarball it generates a huge
> new httpd.conf, full of the crap that I've spent ages slowly whittling
> away from it :(
What do you mean? I can't see any crap in it. What things you didn't want
to show up (do you mean the prefork and other unrelated config chunks?)
just disregard those, since they certainly have nothing to do with the
problem. The good thing is that we can pass the tarball around w/o having
a problem with hardcoded path, which your originally submitted config file
had, which is certainly not runnable on my machine without painful manual
tweaks.
If you want to keep your config file in this tarball to a minimum create:
t/conf/steve.conf.in
or
t/conf/steve.last.conf.in
depending on when do you do you want it to be included. and put all the
stuff there. It will be automatically included on t/TEST -conf.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>Sadly not. Attached is the .tar.gz that I made, but it passes all tests
>successfully!
>
I wish my mail program would warn me if I send a mail including the word
"attached" but the mail doesn't have an attachment :) Here it is...
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>
>>>I'll try whittling down the conf even further.
>>>
>>>
>>>
>>The attached conf & extra startup script is fairly minimal and still
>>causes this sequence to crash:
>>
>> perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>>
>>But if I comment-out the line:
>>
>> PerlModule TestPerl::hash_attack
>>
>>then the tests succeed.
>>
>>If I restore that line, but change t/response/TestPerl/hash_attack.pm so
>>that it only contains:
>>
>> package TestPerl::hash_attack;
>> 1;
>>
>>then ithreads.t crashes again!
>>
>>Bizarre. Is this worth pursuing any further?
>>
>>
>
>I have some ideas. I wonder if those notes from xs/APR/Pool/APR__Pool.h
>could be relevant to this problem:
>
>/* XXX: this implementation has a problem with perl ithreads. if a
> * custom pool is allocated, and then a thread is spawned we now have
> * two copies of the pool object, each living in a different perl
> * interpreter, both pointing to the same memory address of the apr
> * pool.
> *
> * need to write a CLONE class method could properly clone the
> * thread's copied object, but it's tricky:
> * - it needs to call parent_get() on the copied object and allocate a
> * new pool from that parent's pool
> * - it needs to reinstall any registered cleanup callbacks (can we do
> * that?) may be we can skip those?
> */
>
>In your minimum setup try to get rid of most of the parts in:
>
>C:\Temp\mod_perl-2.0\t\conf\modperl_extra.pl
>
>and make sure that no pool cleanup is registered and see if you still get
>a crash.
>
>
I'll look into this. How do I tell if any pool cleanup is registered,
though?
>Again, you will probably make a much nicer progress using
>http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
>
Sadly not. Attached is the .tar.gz that I made, but it passes all tests
successfully!
As noted before, the minimal configuration that I've come up with myself
(i.e. not involving the bug reporting skeleton) seems to be sensitive to
the inclusion or otherwise of seemingly unrelated code / directives.
The slightest deviation from the conf that I last posted can result in
the tests suddenly working, hence the bug reporting skeleton is no good
here since it doesn't give me anything like the control over the
httpd.conf that I seem to need.
When I run "nmake test" with the attached tarball it generates a huge
new httpd.conf, full of the crap that I've spent ages slowly whittling
away from it :(
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead, we will be making a donation to charity.
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Steve Hay wrote:
>
>
>>I'll try whittling down the conf even further.
>>
>
> The attached conf & extra startup script is fairly minimal and still
> causes this sequence to crash:
>
> perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>
> But if I comment-out the line:
>
> PerlModule TestPerl::hash_attack
>
> then the tests succeed.
>
> If I restore that line, but change t/response/TestPerl/hash_attack.pm so
> that it only contains:
>
> package TestPerl::hash_attack;
> 1;
>
> then ithreads.t crashes again!
>
> Bizarre. Is this worth pursuing any further?
I have some ideas. I wonder if those notes from xs/APR/Pool/APR__Pool.h
could be relevant to this problem:
/* XXX: this implementation has a problem with perl ithreads. if a
* custom pool is allocated, and then a thread is spawned we now have
* two copies of the pool object, each living in a different perl
* interpreter, both pointing to the same memory address of the apr
* pool.
*
* need to write a CLONE class method could properly clone the
* thread's copied object, but it's tricky:
* - it needs to call parent_get() on the copied object and allocate a
* new pool from that parent's pool
* - it needs to reinstall any registered cleanup callbacks (can we do
* that?) may be we can skip those?
*/
In your minimum setup try to get rid of most of the parts in:
C:\Temp\mod_perl-2.0\t\conf\modperl_extra.pl
and make sure that no pool cleanup is registered and see if you still get
a crash.
Again, you will probably make a much nicer progress using
http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Steve Hay wrote:
>
>
>>I'll try whittling down the conf even further.
>>
>
> The attached conf & extra startup script is fairly minimal and still
> causes this sequence to crash:
>
> perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
>
> But if I comment-out the line:
>
> PerlModule TestPerl::hash_attack
>
> then the tests succeed.
>
> If I restore that line, but change t/response/TestPerl/hash_attack.pm so
> that it only contains:
>
> package TestPerl::hash_attack;
> 1;
>
> then ithreads.t crashes again!
>
> Bizarre. Is this worth pursuing any further?
It certainly worth doing that, but if I can't reproduce it I can't debug
it :( I suppose worker is a bit different than winnt.
Could you at least re-pack that failing setup in
http://apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
and post it here, so it's easier to try to reproduce it. 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>I'll try whittling down the conf even further.
>
The attached conf & extra startup script is fairly minimal and still
causes this sequence to crash:
perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
But if I comment-out the line:
PerlModule TestPerl::hash_attack
then the tests succeed.
If I restore that line, but change t/response/TestPerl/hash_attack.pm so
that it only contains:
package TestPerl::hash_attack;
1;
then ithreads.t crashes again!
Bizarre. Is this worth pursuing any further?
- 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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>
>>Are we sure that the PerlInterpScope directive should not be at the
>>top-level? If so, then reload.t is OK and we still have ithreads.t to fix.
>>
>>
>
>but it doesn't exist anymore.
>
I know. I wanted to double-check that that is correct. I'm only asking
because putting it back makes the ithreads.t test pass...
------------------------------------------------
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: t/perl/ithreads.t revisited
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Are we sure that the PerlInterpScope directive should not be at the
> top-level? If so, then reload.t is OK and we still have ithreads.t to fix.
but it doesn't exist anymore. Are you running the latest svn?
% grep -Ir 'PerlInterpScope handler' t
gives nothing.
--
__________________________________________________________________
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: t/perl/ithreads.t revisited
Posted by Steve Hay <st...@uk.radan.com>.
Philippe M. Chiasson wrote:
>Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>>>Next I want you to try cutting off things from startup files and
>>>>>httpd.conf, to find whether it's some unrelated module that is
>>>>>loaded that causes the problem. I suspect that because the sister
>>>>>test t/perl/ithreads2.t doesn't fail, and it runs exactly the same
>>>>>code, but inside a dedicated interpreter pool, which doesn't load
>>>>>any other modules.
>>>>>
>>>>>
>>>>Will try (again), but I've tried this before and got nowhere with it :(
>>>>
>>>>
>>>>
>>>While trawling through the httpd.conf file I found a couple of what
>>>look like errors: Two places say "PERL_ITHREADS" instead of
>>>"PERL_USEITHREADS". Correcting these apparent mistakes fixes the
>>>broken test sequence previously reported!
>>>
>>>
>>[...]
>>
>>
>>
>>>After making this change I found that reload.t now fails test 2. This
>>>patch (against current CVS, since I can't get SVN working) fixes that:
>>>
>>>Index: t/modules/reload.t
>>>===================================================================
>>>RCS file: /home/cvspublic/modperl-2.0/t/modules/reload.t,v
>>>retrieving revision 1.4
>>>diff -u -u -r1.4 reload.t
>>>--- t/modules/reload.t 11 Sep 2004 01:02:28 -0000 1.4
>>>+++ t/modules/reload.t 26 Nov 2004 18:05:21 -0000
>>>@@ -53,7 +53,7 @@
>>> touch_mtime($test_file);
>>>
>>> {
>>>- my $expected = join '', map { "$_:" . uc($_) . "\n" } sort @tests;
>>>+ my $expected = join '', map { "$_:$_\n" } sort @tests;
>>> my $received = get_body($same_interp, \&GET, $location);
>>> $skip++ unless defined $received;
>>> skip_not_same_interp(
>>>
>>>
>
>That's not a correct fix to the problem. reload.t is apparently now failing for
>you, and this patch just ignores the failure.
>
OK, current state of play is this:
With fresh svn check-out, all tests pass OK if I skip t/perl/ithreads,
but with t/perl/ithreads the server crashes on that test.
As before, this sequence reliably fails:
perl t/TEST -verbose t/modules/reload.t t/perl/api.t t/perl/ithreads.t
It still fails with the attached much-shortened conf file. Note that
I've commented-out a top-level PerlInterpScope directive, in line with
recent changes. If I re-instate that directive then t/perl/ithreads no
longer crashes, but t/modules/reload fails as described above.
Are we sure that the PerlInterpScope directive should not be at the
top-level? If so, then reload.t is OK and we still have ithreads.t to fix.
I'll try whittling down the conf even further.
- 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.