Re: A fix in sight: Apache::ASP: crash when placed in startup.pl
On Wed, Jan 19, 2000 at 09:11:51AM +, Alan Burlison wrote: > > 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. Seems reasonable. Though people will object to the overhead for normal perl unless it only does it when perl_destruct_level > 0 (as it is for mod_perl and should be for all embedded perls). Also, the mod_perl patch I just saw posted should probably remove entries from DynaLoader::dl_librefs as it unloads them. Likewise for any new DynaLoader END code. That way they'll play safe together. Tim. [Architect and author of much of DynaLoader in years gone by.]
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] | \/ \/
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
> > > > > > > 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)
> 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
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)
Gerald Richter wrote: > Just one more thought: The mp_dso_unload, which Daniel has patched, is > registered as cleanup. So it should be called everytime the modperl > libraries is unloaded and only when modperl library is unloaded, we need to > unload the other libraries. So as far as I see this patch is all that is > neccessary. I am missing something? 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. Alan Burlison
RE: A fix in sight: Apache::ASP: crash when placed in startup.pl
On Wed, 19 Jan 2000, Gerald Richter wrote: > > > > 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(). > 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! excellent! > 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? let's hold off for a little bit, I'd like to understand the problem better and do some testing of my own first.
RE: A fix in sight: Apache::ASP: crash when placed in startup.pl (2)
> > > > 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. > > > Just one more thought: The mp_dso_unload, which Daniel has patched, is registered as cleanup. So it should be called everytime the modperl libraries is unloaded and only when modperl library is unloaded, we need to unload the other libraries. So as far as I see this patch is all that is neccessary. I am missing something? 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
> > 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
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. thanks again!!
Re: A fix in sight: Apache::ASP: crash when placed in startup.pl [Fwd: redhat 6.1 rpm for apache]
well al i know is i have stampede running it quite fine!!
lol
when a buncha volunteers can get it working better than an ipo!
lol
where does the money flow
my modperl status {perl-status} shows
Embedded Perl version 5.00503 for Apache/1.3.6 (Unix) mod_perl/1.19
on
kernel 2.2.5
stampede 0.89 with modified perl from 0.90 comp'd myself
now i compiled and installed apache and modperl myself
the time taken to track down the source of this error in redhat
has taken so much time i should have trusted my first insctinct and
recompiled them myself!
or used some other distribution!
ttfn
Re: A fix in sight: Apache::ASP: crash when placed in startup.pl
On Sat, Jan 15, 2000 at 08:58:35PM -0500, Daniel Jacobowitz wrote:
> Thus my confusion. On Linux, with a static libperl.a, there are no
> multiple copies of libperl.so floating around to link to. The symbols
> only exist in one place. Thus there is no choice about what symbols
> link to. Still, I'm going to go over my linker logs again and see if
> something useful turns up on that front.
Ah-HA!
I believe I see the problem. In fact, I'm almost sure I do.
>From the one useful ltrace log I was able to get:
% grep '^dl' min.ltrace.log
dlopen("/usr/lib/apache/1.3/mod_cgi.so", 258) = 0x080a4198
dlsym(0x080a4198, "cgi_module") = 0x40187540
dlopen("/usr/lib/apache/1.3/mod_mime.so", 258)= 0x080a4518
dlsym(0x080a4518, "mime_module") = 0x40017a00
dlopen("/usr/lib/apache/1.3/mod_perl.so", 258)= 0x080a4850
dlsym(0x080a4850, "perl_module") = 0x402b6bc0
dlopen("/usr/lib/perl5/5.005/i386-linux/"..., 1) = 0x08118e60
dlsym(0x08118e60, "boot_DBI") = 0x402e4834
dlclose(0x080a4850) = 0
dlclose(0x080a4518) = 0
dlclose(0x080a4198) = 0
dlopen("/usr/lib/apache/1.3/mod_cgi.so", 258) = 0x0817f958
dlsym(0x0817f958, "cgi_module") = 0x40187540
dlopen("/usr/lib/apache/1.3/mod_mime.so", 258)= 0x080afcb8
dlsym(0x080afcb8, "mime_module") = 0x4018aa00
dlopen("/usr/lib/apache/1.3/mod_perl.so", 258)= 0x080a4170
dlsym(0x080a4170, "perl_module") = 0x402b9bc0
dlopen("/usr/lib/perl5/5.005/i386-linux/"..., 1) = 0x08118e60
dlsym(0x08118e60, "boot_DBI") = 0x402e4834
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!
But now they are resolved to the wrong places.
This looks to be precisely contrary to the way that the linker is
supposed to work, but I'll get back to that later.
Thus my question is, is there a way to tell perl to dlclose() all
modules? From looking through the perl code and seeing a noticeable
lack of dlclose() calls, I'd say no. DynaLoader doesn't seem to
support unloading things. It does, however, store the loaded dlopen
handles in @DynaLoader::dl_librefs, which we could get at in a cleanup.
Woah!
This worked! Can I get opinions on the attached patch?
Dan
/\ /\
| Daniel Jacobowitz|__|SCS Class of 2002 |
| Debian GNU/Linux Developer__Carnegie Mellon University |
| [EMAIL PROTECTED] | | [EMAIL PROTECTED] |
\/ \/
--- mod_perl.c.orig Sat Jan 15 22:08:27 2000
+++ mod_perl.c Sat Jan 15 22:13:01 2000
@@ -417,23 +417,30 @@
#if MODULE_MAGIC_NUMBER >= MMN_130
static void mp_dso_unload(void *data)
{
-module *modp;
-
-if(!PERL_DSO_UNLOAD)
- return;
-
-if(strEQ(top_module->name, "mod_perl.c"))
- return;
-
-for(modp = top_module; modp; modp = modp->next) {
- if(modp->dynamic_load_handle) {
- MP_TRACE_g(fprintf(stderr,
- "mod_perl: cancel dlclose for %s\n",
- modp->name));
- modp->dynamic_load_handle = NULL;
+ I32 i;
+ void *handle;
+ AV *librefs;
+ SV *handle_sv;
+
+ librefs = perl_get_av("DynaLoader::dl_librefs", FALSE);
+ if (!librefs) {
+ MP_TRACE(fprintf(stderr, "Could not get @dl_librefs for
+unloading.\n"));
+ return;
}
-}
-}
+
+ for(i = 0; i <= AvFILL(librefs); i++) {
+ handle_sv = *av_fetch(librefs, i, FALSE);
+ if(!handle_sv) {
+ MP_TRACE(fprintf(stderr, "Could not fetch $dl_librefs[%d]!\n",
+i));
+ continue;
+ }
+ handle = (void *)SvIV(handle_sv);
+ if(dlclose(handle) < 0) {
+ fprintf(stderr, "Could not close $dl_librefs[%d]: %s\n", i,
+dlerror());
+ continue;
+ }
+ }
+}
#endif
static void mp_server_notstarting(void *data)
