perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [PATCH] Re: t/perl/ithreads.t revisited
Date Tue, 14 Dec 2004 14:54:46 GMT
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


Mime
View raw message