Front page | perl.perl5.porters |
Postings from January 2004
So we get these 'free to wrong pool' errors on winfu, usually under ithreads when the interpreter context is wrong and a memory from the wrong pool is allocated. This is all dandy, but it doesn't make it any easy to find the place where the problem is, as it complains at the perl_destruct stage. What would it take to make windows implementation complain about the wrong pool when the variable is asking to allocate the memory, or immediately after it, so the trace will pinpoint the place with a problem. I'm not familiar with the implementation but may be something like: allocate the memory, then free it and then allocate again? will that work? The bottom line is that the same application behaves differently under winFU and non-winFU perl versions. So if I'm a non-winFU developer and have a user reporting a problem with my application on winFU, I should be able to reproduce this problem on non-winFU platform. Please notice that this has nothing to do with OS-specifics, like file system, signals or what not, but just memory allocation/freeing implemented purely by Perl itself. How do we make perl behave identically, so that if my program works on unix it will work on winFU just the same (minus the perlport.pod issues). If you think that there is no way to make winFU perl memory allocation behave like non-winFU perl, give us an option to make non-winFU perl behave like winFU perl, so we can debug our perl programs w/o needing to buy heaps of sw, install and learn winFU, just to be able to resolve problems for the unfortunate users of winFU. How hard would it be to emulate memory pools per thread for non-winFU perl? I'm talking about a compile time option of course. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.comThread Next