Hi Stas
Sorry, are you saying that you feel the problem is in the Perl code rather than mod_perl ? I managed to track the fact that the Perl_safesysfree() is a Perl method, but could not determine if that was the cause or another symptym of the error we are seeing.
Frankly, Darren, I wasn't really participating in mp1 C guts development, so it takes me ages to figure things out there. Besides you didn't give us a reproducable test case, trying to reproduce things in the head is a "bit" hard. Finally I'm now fully concentrated on polishing mp2 API, so I'm really not in position to try to allocate a lot of time to try to figure out what's wrong. I just tried to answer some of your questions, looking a bit at where the problem may come from. Hopefully someone else can try to reproduce that case and see what's wrong.
Philippe, are you around? Can you take a look at this issue?
Below are some additional sections of the truss that document where the memory reference gets used and within which mod_perl functions. (The number are just line numbers for my reference)
I believe the actual problem is somewhere in the perl_cmd_handler_handlers that releases the memory, when obviously it is still required. Again I don't know if this is a mod_perl or perl error.
mod_perl usually doesn't explicitly free memory, it could be that some SV's ref count went to 0, triggering the freeing. But grep for explicit free calls. If you get the same address all the time, you could set a watchpoint for that address and get a backtrace when you hit the safesysfree call, that will show where exactly the freeing is coming from.
I have noticed that if all I do is load the libperl.so, but do not include the PerlRequire to setup the additional libraries (Apache.pm, etc) then both modules will load ok and we don't see this error. The problem being that mod_perl doesn't then work ;)
Does this help to narrow this down ???
3373941 -> mp_dso_unload 3397095 - 0xcf7c8 starts being used again by mod_perl (Perl_safesysfree) 3397485 - 0xcf7c8 appears to be cleared (Perl_safesysfree) 3631510 <- mp_dso_unload
6375068 -> ap_process_request - processes first request and then seg faults
I suppose it's coming from perl_shutdown below:
static void mp_dso_unload(void *data)
{
array_header *librefs; librefs = xs_dl_librefs((pool *)data);
perl_destruct_level = 2;
perl_shutdown(NULL, NULL);
unload_xs_so(librefs);
}Try to play with the perl_destruct_level value (try 1 and 0).
This latter trace is definitely better, but still all the allocs/deallocs happen in the perl land, not mod_perl as far as I can see. So your best bet is to do what I suggested above. Set a watchpoint for that problematic address and get real stack traces every time it's allocated or freed (or accessed and may be refcounting is going wrong there). Once you have that you will know exactly who's fault it is.
If you look at perl_do_file, it doesn't free any memory explicitly.
-- __________________________________________________________________ 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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
