perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: ithreads.t again
Date Tue, 08 Feb 2005 10:13:16 GMT
Stas Bekman wrote:

>Steve Hay wrote:
>>In fact, I think an earlier change that was made to APR::Error::str() to 
>>have it sprintf() into a lexical $str and return that, rather than just 
>>doing "return sprintf ...", looks like it was unnecessary.  Both of the 
>>above test sequences still succeed at the moment for me even with that 
>>change reverted :(  It must just have been a fluke that it fixed things 
>>at the time.
>in which case we should revert that. Please post a patch that still works 
>for you.

The test sequence that original patch was meant to fix (modules/reload 
perl/api perl/ithreads) currently passes OK with the attached patch 
applied (i.e. the original patch reverted), as do the two more recently 
failing sequences (filter/in_error modules/reload perl/api 
perl/ithreads, and filter/out_str_lc modules/reload perl/api 
perl/ithreads), although the full test suite still fails if the 
t/ithreads.t tests are included.

The full test suite passes OK if the t/ithreads.t tests are skipped, though.

>>I wonder if the real cause is anything to do with perlbug 34069 or 24254?
>well, there are no threads involved there, so it could be something else.
It's the same error message that I've seen, though.  Maybe we've just 
been lucky in not seeing anything amiss with non-threaded stuff.  The 
bug looks like a double-free error ($_ being freed twice - once by the 
inner loop, once by the outer loop), which could well cause the sort of 
"random" behaviour that we're seeing.

I'd love to get that perl bug fixed and then see if our ithreads.t 
problems go away.

- Steve

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.

View raw message