Stas Bekman wrote: >Steve Hay wrote: >[...] > > >>One thought that I just about this stuff: I know that Linux users have >>always been unable to reproduce this behaviour. Which malloc() are you >>using? I'm using Perl's malloc() now (although admittedly I was using >>the system malloc() before). If you're using the system malloc() it >>might just be worth a try with Perl's malloc() instead to see if it >>makes any difference. >> >> > >I've build 5.8.6 with mymalloc, but no difference with any of: > >t/TEST -v filter/out_str_lc.á modules/reload.t perl/api.t perl/ithreads.t >t/TEST -v filter/in_error.t modules/reload.t perl/api.t perl/ithreads.t > Shame. Thanks for trying anyway.
Interestingly, neither of the above sequences fail for me at the moment either! All that's changed is the addition of the Apache::Reload patch to modperl_util.c plus the accompanying test (adding "sub promised;" to t/modules/reload.t). Reverting the modperl_util.c change makes no difference to this, but reverting the reload.t change makes the failures re-appear! It looks more and more like some random memory corruption, just like the random failures that you find on Linux. Maybe Win32 sets thing up in memory the same way each time I run the program, but is sensitive to very slight changes in the program being run, whereas Linux doesn't even set things up the same each time anyway? 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. 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 - 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.
