perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: [PATCH] Re: t/perl/ithreads.t revisited
Date Tue, 14 Dec 2004 15:39:29 GMT
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.
Mime
View raw message