Received: (qmail 1031 invoked from network); 10 Mar 1999 21:22:22 -0000
Message-Id: <199903102123.QAA18308@siam.gensym.com>
Date: Wed, 10 Mar 1999 16:23:00 -0500 (EST)
From: bhyde@pobox.com
To: tv@pobox.com
Cc: apbugs@Apache.Org
Subject: os/unix/os.c dlclose()s objects before module cleanups are complete

>Number:         4029
>Category:       pending
>Synopsis:       os/unix/os.c dlclose()s objects before module cleanups are complete
>Confidential:   yes
>Severity:       non-critical
>Priority:       medium
>Responsible:    bhyde
>State:          closed
>Class:          duplicate
>Submitter-Id:   unknown
>Arrival-Date:   Wed Mar 10 13:30:00 PST 1999
>Last-Modified:  Thu Mar 11 13:21:37 PST 1999
>Originator:     
>Organization:
>Release:        
>Environment:
>Description:
>How-To-Repeat:
See "mod_perl interfering with `regular' CGI?" recent thread on the
modperl list.  E-mail if you need further details.

I'm sorry a few quick moments of looking and I couldn't find the
modperl list's archives online.

How confident are you that this was actually what happened?  Can
you identify the "cleanup" operation that triggered the segv so
I can admit both that such a cleanup can happen after the module
is unloaded and that the module had was using it approprately.

 - ben hyde
>Fix:
>Audit-Trail:
State-Changed-From-To: open-closed
State-Changed-By: bhyde
State-Changed-When: Thu Mar 11 13:21:36 PST 1999
State-Changed-Why:
bug generated by a bad email subject
Class-Changed-From-To: sw-bug-duplicate
Class-Changed-By: bhyde
Class-Changed-When: Thu Mar 11 13:21:36 PST 1999
Severity-Changed-From-To: serious-non-critical
Severity-Changed-By: bhyde
Severity-Changed-When: Thu Mar 11 13:21:36 PST 1999
Responsible-Changed-From-To: gnats-admin-bhyde
Responsible-Changed-By: bhyde
Responsible-Changed-When: Thu Mar 11 13:21:36 PST 1999
Responsible-Changed-Why:
fool who sent the bad mail
>Unformatted:
>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).
The only exceptions are that subpools are cleared before any parent
pool cleanups, and subprocesses of a pool are shutdown after the pools
are cleared.

The ap_cleanup_for_exec cleanups mod_so registered don't do anything,
so the code is not unloaded as a side effect of ap_cleanup_for_exec

>This is bad, because a module which is loaded with LoadModule may
>register cleanups that Apache attempts to run _after_ it has dlclose()d
>that module.  

To have this happens you need to load the module and then have
the module register a callback (not necessarily a cleanup) that
can be invoked after the server is next reset.

I can imagine, but it's hard, doing that but not within the usual Apache
framework.

>This results in a hard to trace back SIGSEGV.
> 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.