httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject Re: mod_ssl broken as DSO in HEAD
Date Tue, 17 Jun 2003 20:34:13 GMT

On June 17, 2003 04:06 pm, Justin Erenkrantz wrote:
> --On Tuesday, June 17, 2003 12:46 PM -0500 "William A. Rowe, Jr."
> <> wrote:
> > If folks would be so kind as to cvs up their httpd-2.1 trees and
> > check out the latest cleanup reordering and introduction of ENGINE_
> > and CONF_ cleanups - I would be most grateful.
> >
> > Geoff, if you could review the latest commit for sanity, I'd
> > appreciate that, too.
> Nope, still SEGVs in the same location even though the cleanups are
> invoked. -- justin

Well first off, the original backtrace showed a segfault down inside the 
bowels of the error handlers, something to do with CRYPTO_thread_id() 
IIRC. That you were getting this, combined with the fact you couldn't get 
a segfault under a different debugger and/or other variations of running 
it (again, IIRC), would suggest that at least part of what you're seeing 
is environmental and/or platform specific. You would still have been 
getting library errors of course, but it doesn't explain away the 

But with respect to the missing cleanups; it's quite possible that adding 
those cleanup calls won't guarantee complete unloading if there are 
references left lingering by the application code. If there are objects 
allocated (or references held) by Apache code, these should all be 
released prior to calling the cleanup functions otherwise things will be 
left lingering. The cleanup functions should only release the references 
held by the library's internal state - the application must do it's part 
too. This includes any of the following objects mod_ssl may have lying 
around; RSA, DSA, EVP_PKEY, SSL, SSL_CTX, ENGINE, X509, ... (you get the 
picture). Note that these things can have references between them, eg. an 
SSL object may hold a reference to an RSA key which in turn may hold a 
reference to an ENGINE, etc. This is why the easiest way usually to track 
down this sort of thing is to run the cleanup, exit(0), and then check 
for memory leaks using valgrind or whatever.

Other than those vague thoughts, I can't suggest much else. If this 
continues to resist your efforts, please let me know how I can reproduce 
and debug this (in linux) from the apache point of view. I'm a bit 
shallow in my knowledge of apache's internals and how to track its 
loading, unloading, memory handling, etc.


Geoff Thorpe

View raw message