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. Bill 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 >linking). > >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 :-) > >Cheers, >Geoff > >-- >Geoff Thorpe >[EMAIL PROTECTED] >http://www.geoffthorpe.net/
