RE: A fix in sight: Apache::ASP: crash when placed in startup.pl
perl_destruct/perl_free are not called at restart, only during child_exit. it looks like that might need to change to finish the dso puzzle. I experienced some problems there, but that was a few years ago, looks like it's time to revisit. But it is called when Apache unloads the modules during startup. Therefore my Apache on NT starts cleanly without the PERL_STARTUP_DONE_CHECK workaround :-) and Embperl works the first time on Unix when it's loaded at startup time and mod_perl is dynamicly linked. Really great! Doug, I have the patch (with dlclose replaced with ap_os_dso_unload, as I posted some hours ago) here in the CVS working directory, should I commit it? Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: A fix in sight: Apache::ASP: crash when placed in startup.pl
Doug MacEachern wrote: wow, *nice* catch!! Daniel, I can't thank you and Alan enough for your efforts here. it's such a thorny problem to debug, the closest I came was trying to prevent the dlclose of modperl's libperl.so, but had no idea why that bandaid prevented the bleeding. I hadn't heard of ltrace, what a spectacular looking tool. I'd really like to get the workaround in 1.22, even if Apache and/or DynaLoader is the "right" place, we don't have any control over the release schedules of either and modperl-1.22 is already long overdue. You are welcome - it has always bugged me that I could never get APXS to work. Both Perl and Apache are included with Solaris 8 (http://www.sun.com/software/solaris/ea/linux.html), and the only way to add mod_perl to the preinstalled Apache/Perl is to use APXS. I've posted a bug against DynaLoader to P5P. I think the fix is probably to put an END handler in DynaLoader to unload the XS modules, but I'm not familiar enough with the perl interpreter cleanup processing to know if this is the best way. It might add some weight if you could add your comments to the bug preport in P5P - after all, the know who you are ;-) Alan Burlison
RE: A fix in sight: Apache::ASP: crash when placed in startup.pl (2)
Seems correct to me, although as I said before the patch should really go in DynaLoader - after all it is conceivable that perl embedders other than Apache could be hit by this problem. Yes, I agree, but this will not before perl 5.006 and much people are still using perl 5.004... Gerald
RE: A fix in sight: Apache::ASP: crash when placed in startup.pl
perl_destruct/perl_free are not called at restart, only during child_exit. it looks like that might need to change to finish the dso puzzle. I experienced some problems there, but that was a few years ago, looks like it's time to revisit. But it is called when Apache unloads the modules during startup. Therefore not perl_destruct()/perl_free(), they are only called in mod_perl by perl_shutdown(), during child_exit(). Aah, now I understand. I didn't get it the right way from your first mail. Yes, perl_destruct()/perl_free() should also be called before the XS libraries are unloaded, to give perl a chance to cleanup. Gerald
Re: A fix in sight: Apache::ASP: crash when placed in startup.pl (2)
Gerald Richter wrote: Seems correct to me, although as I said before the patch should really go in DynaLoader - after all it is conceivable that perl embedders other than Apache could be hit by this problem. Yes, I agree, but this will not before perl 5.006 and much people are still using perl 5.004... This is unfortunately true. However, the next version of perl is imminent (ish) so it would be nice if the fix could be in it. Alan Burlison
Re: A fix in sight: Apache::ASP: crash when placed in startup.pl
On Tue, Jan 18, 2000 at 11:02:27PM -0800, Doug MacEachern wrote: On Sat, 15 Jan 2000, Daniel Jacobowitz wrote: ... Notice that DBI is never dlclose()'d. But mod_perl is, when apache unloads its modules. The linker is not clever enough to realize that DBI depends on symbols in mod_perl.so. When mod_perl is reloaded at a DIFFERENT address, DBI has no reason to be rebound; its symbols are already resolved! wow, *nice* catch!! Daniel, I can't thank you and Alan enough for your efforts here. it's such a thorny problem to debug, the closest I came was trying to prevent the dlclose of modperl's libperl.so, but had no idea why that bandaid prevented the bleeding. I hadn't heard of ltrace, what a spectacular looking tool. I'd really like to get the workaround in 1.22, even if Apache and/or DynaLoader is the "right" place, we don't have any control over the release schedules of either and modperl-1.22 is already long overdue. perl_destruct/perl_free are not called at restart, only during child_exit. it looks like that might need to change to finish the dso puzzle. I experienced some problems there, but that was a few years ago, looks like it's time to revisit. *blink* Oh, you're right, of course. They weren't getting called at all. I think that's a problem, and I have a good idea of how to go about fixing it - I'll get back to you on that in a few hours. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
DSO SEGV fix (was: A fix in sight: Apache::ASP: crash when placed in startup.pl)
Daniel Jacobowitz [EMAIL PROTECTED] writes: This worked! Can I get opinions on the attached patch? I am not competent to check whether the patch has any hidden problems, but I hope Doug will be able to evaluate it and include it in the next release. Your description of the sequence leading up to the crash fits well with what I observed when trying to trace the problem with gcc. It looks like Alan Burlison is on to a different dynamic linking problem that also needs to be fixed. -- Frank Cringle, [EMAIL PROTECTED] voice: (+49 2304) 467101; fax: 943357
Re: DSO SEGV fix (was: A fix in sight: Apache::ASP: crash when placed in startup.pl)
"Frank D. Cringle" wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: This worked! Can I get opinions on the attached patch? I am not competent to check whether the patch has any hidden problems, but I hope Doug will be able to evaluate it and include it in the next release. Your description of the sequence leading up to the crash fits well with what I observed when trying to trace the problem with gcc. It looks like Alan Burlison is on to a different dynamic linking problem that also needs to be fixed. No, it's the exactly the same problem, and the fix works for me too. Alan Burlison
