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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
