At 11:53 PM -0500 3/5/06, John E. Malmberg wrote: >> >> >>EAGLE> search thread_test.log failed >>t/comp/cpp.............................FAILED--no leader found > >This was caused by access violations because Newx() is being used to allocate >memory in a path taken by vms_image_init. > >I changed the Newx calls to PerlMem_malloc to get around the problem, and now >I am trying to find the cause of: > >MCR perl_build_root:[000000]miniperl.exe "-I[---.lib]" "-I[---.lib]" >"-MExtUtils::Command" -e mv Descrip.MMS Descrip.MMS_old >panic: free from wrong pool. >Scalars leaked: 1 >%SYSTEM-F-ABORT, abort >
Most likely it's because the Perl memory routines keep track of which thread you're in when memory is allocated and then give you a hard time about it when it's deallocated from a different thread. If you allocate memory during start-up, before thread context has been initialized, the thread it thinks you're in at allocation time is either null or something random off the stack (I can't remember which), but when you deallocate after thread initialization, there is a real, valid thread context that is different from the bogus one it has squirrelled away and with which it does a comparison. The only way I've found around this is to skip the Perl memory routines entirely during start-up. It would be nice if there were a way to detect that thread context has not been initialized and have the memory allocations not attempt to store (bogus) thread context in those cases. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
