Steve Hay wrote:
Attached.
It won't apply for me, but I've tweaked it manually and committed.
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.
same here, but randomly. If I'll have time I'll try to get that win32-like pool perl patch working again (the one that Jan has submitted in chunks some time ago) and see if I can reproduce the failure in a more predictable way.
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?
http://rt.perl.org/rt3/index.html?q=34069
http://rt.perl.org/rt3/index.html?q=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.
Please let us know the outcome of that thread.
-- __________________________________________________________________ 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]
