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.
Finally got a chance to dig some more and found that if I add:
CRYPTO_set_id_callback(openssl_id);
to ssl_hook_pre_config before the ENGINE_load_builtin_engines and where openssl_id is defined as:
static unsigned long openssl_id(void)
{
/* FIXME: This is lame and not portable. -aaron */
return (unsigned long) apr_os_thread_current();
}(The above is used in flood - hence Aaron's comment.)
The SEGVs go away if we do this. Does this make sense given the internals of OpenSSL?
On this same tangent, do we need to be doing all of the CRYPTO_<lock> stuff? I don't believe we are doing that. And, I know in flood, we had lots of problems until we called them. So, I think mod_ssl should be passing the lock structures - especially for worker MPM builds...
While I've got someone's attention, I have some real issues in that both of the OpenSSL lock implementations (CRYPTO_set_locking_callback and CRYPTO_set_dynlock_*) require global variables to implement. I don't think I can say 'ick' loud enough.
What would the possibility/feasibility of passing application-specific opaque values through the CRYPTO_lock callbacks? Say
static void openssl_lock(int mode, int n, void *app, const char *file, int line)
static CRYPTO_dynlock_value *ssl_dyn_create(void *app, const char* file, int line)
We can have app passed into the CRYPTO_set functions - in the case of httpd, it would be the pools for ssl_dyn_create *or* the global array of locks that openssl_lock would require. You don't know how much happier that would make me if we could do that. globals are just so icky. -- justin
