httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: mod_ssl broken as DSO in HEAD
Date Tue, 17 Jun 2003 17:46:02 GMT
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.


At 12:17 PM 6/17/2003, Geoff Thorpe wrote:
>Hi there,
>On June 16, 2003 10:14 pm, William A. Rowe, Jr. wrote:
>> At 08:13 PM 6/16/2003, Justin Erenkrantz wrote:
>> >The change to move OpenSSL's initialization to ssl_hook_pre_config is
>> > busted when mod_ssl is a DSO.  It will try to call all of the OpenSSL
>> > init sequences twice which I don't believe OpenSSL supports.
>> We may need to register proper 'cleanups' to 'unload' all of the
>> engines, as you point out in this problem;
>If things really are supposed to initialise (and unload) two times on 
>startup, then I guess this is what you should do for openssl too.
>> Right.  What is more interesting (as a DSO) is that our module, and
>> ergo the SSL library, should have been unloaded and reinitialized. 
>> Apparently we can't count on that behavior, though.
>Depending on what gets initialised, there are a variety of things you 
>might need to unload from openssl's point of view. However, this is 
>usually an issue for people from a memory leak point of view, not a 
>double initialisation. Potential issue: in a few places, openssl uses a 
>global "is_set" variable to handle first-time initialisation of callbacks 
>(eg. malloc). The idea is that once they're set, they can't be overriden. 
>If you don't need to do *that* twice on startup, there's no problem. If 
>you do, then it shouldn't matter *provided* you can live without error 
>checking - if it fails then the (correct) global is still set from the 
>previous initialisation, and if it succeeds then the globals needed 
>setting anyway. Of course if it fails on the first initialisation then 
>you have a bug that you'll never spot ... BTW: this is only for stuff 
>where you are providing callback overrides for memory management, thread 
>locking, error stacks, etc.
>> Well, if it isn't done before pre-config, the entire ENGINE support
>> code in the command handler for SSLCryptoDevice is borked.  I know, I
>> already spent two days there.
><gulp> SSLCryptoDevice ... I don't like the sound of that ;-)
>> If we force the SSL Library to stay loaded (reliably, across platforms)
>> between startup phases (with the SSL module itself unloading and
>> reloading - ick), then saving the initialization in pprocess might be a
>> viable alternative, but where?  register_hooks is no better than
>> pre_config in this regard.
>> Or we simply work out an ENGINE_unload_engines() as a cleanup.  But of
>> course, OpenSSL doesn't really like to be cleared and restarted from
>> scratch, so I don't know if this is really trivial or a nightmare.
>This can be done easily enough, it's just a case of knowing what bits you 
>need to clean up. What is beyond my reach however is a way of convincing 
>Apache to run in one process and start up and close down cleanly - this 
>is normally the easiest way to check for missing cleanups because they 
>show up as leaks. I could otherwise give you some tips on cleanup 
>sequences, but without a way of checking the cleanup code for leaks we'd 
>be acting on faith that the sequence is (a) complete, and (b) the minimum 
>necessary (no point putting redundant calls in and risking extra static 
>Let me know if, and how, I can help. If you want to hunt around yourself, 
>check out the "apps_startup()" and "apps_shutdown()" macro definitions 
>inside apps/apps.h in the openssl source. You may not need all of those 
>cleanups, and of course YMMV :-)
>Geoff Thorpe

View raw message