Hi, On June 17, 2003 04:06 pm, Justin Erenkrantz wrote: > --On Tuesday, June 17, 2003 12:46 PM -0500 "William A. Rowe, Jr." > > <[EMAIL PROTECTED]> 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 segfaults. 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. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
