Received: (qmail 22400 invoked from network); 10 Mar 1999 21:43:05 -0000 Message-Id: Date: Wed, 10 Mar 1999 16:46:54 -0500 (EST) From: Todd Vierling To: bhyde@pobox.com Cc: apbugs@Apache.Org In-Reply-To: <199903102123.QAA18308@siam.gensym.com> Subject: Re: os/unix/os.c dlclose()s objects before module cleanups are complete >Number: 4031 >Category: pending >Synopsis: Re: os/unix/os.c dlclose()s objects before module cleanups are >Confidential: yes >Severity: non-critical >Priority: medium >Responsible: bhyde >State: closed >Class: duplicate >Submitter-Id: unknown >Arrival-Date: Wed Mar 10 13:50:02 PST 1999 >Last-Modified: Thu Mar 11 13:23:36 PST 1999 >Originator: >Organization: >Release: >Environment: >Description: >How-To-Repeat: >Fix: >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: bhyde State-Changed-When: Thu Mar 11 13:23:35 PST 1999 State-Changed-Why: email submitted by mistake. Class-Changed-From-To: sw-bug-duplicate Class-Changed-By: bhyde Class-Changed-When: Thu Mar 11 13:23:35 PST 1999 Severity-Changed-From-To: serious-non-critical Severity-Changed-By: bhyde Severity-Changed-When: Thu Mar 11 13:23:35 PST 1999 Responsible-Changed-From-To: gnats-admin-bhyde Responsible-Changed-By: bhyde Responsible-Changed-When: Thu Mar 11 13:23:35 PST 1999 Responsible-Changed-Why: fool who sent the bad mail >Unformatted: On Wed, 10 Mar 1999 bhyde@pobox.com wrote: : > When a file is loaded via LoadFile or LoadModule on UN*X, it is : > dlopen()ed into memory. : : And a cleanup to unload it is registered in the config. pool. This : is then invoked when the server is restarted or shutdown gracefully. Right, but: : >During cleanups (such as a CGI child calling : >ap_cleanup_for_exec()), the dlclose() hooks are called, but in no : >particular order with respect to other registered cleanup hooks. : : The order is well defined: LIFO, last in first out order (aka stack). From what I saw, this wasn't exactly true, and I'll have to get back to you; I don't have time to search sources for a few days. From memory, Apache was calling dlclose() on LoadFile'd shared objects before calling the cleanup handlers for dependent modules, i.e. (short form): LoadFile .../libm.so LoadFile .../libperl.so LoadModule .../mod_perl.so AddModule ...mod_perl... For some reason, dlclose() was called for libperl BEFORE doing all cleanups for mod_perl. If each library was registered as a separate cleanup, LIFO would probably work, but I don't think that's how it worked. Just as a test case, try hooking into the cleanups for a module which is LoadModule'd and AddModule'd later in the config file than an arbitrary LoadFile'd shared object, say, libintl.so or libz.so or something else not normally linked to Apache. If you put printf()s in the appropriate places, you should see Apache call dlclose() on the LoadFile'd file first, before the module cleanups (and eventual dlclose() of the module too). : so the code is not unloaded as a side effect of ap_cleanup_for_exec Um, that isn't quite true. I specifically saw Apache call dlclose() on the LoadModule/LoadFile'd files when execing a CGI. -- -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)