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; >Namely, that is a problem for ENGINE_load_builtin_engines() which will 'detect' >conflicting engine IDs: > >(dbx 1) where > [1] 0xdd32cbe0(), at 0xdd32cbdf > [2] CRYPTO_thread_id(), at 0xddab652f > [3] ERR_get_state(), at 0xdda72732 > [4] ERR_put_error(0x26, 0x78, 0x67, 0xddac1ca8, 0x72), at 0xdda71e49 > [5] engine_list_add(0x81e9720), at 0xdda586f1 > [6] ENGINE_add(0x81e9720), at 0xdda58a5d > [7] ENGINE_load_dynamic(), at 0xdda5b78e > [8] ENGINE_load_builtin_engines(), at 0xdda5a565 >=>[9] ssl_hook_pre_config(pconf = 0x8197d28, plog = 0x81d5e20, ptemp = 0x81dbe38), >line 245 in "mod_ssl.c" > [10] ap_run_pre_config(0x8197d28, 0x81d5e20, 0x81dbe38), at 0x80dcd07 > [11] main(argc = 2, argv = 0x8046a70), line 640 in "main.c" > >ERR_put_error's third argument (reason) is 0x67 (103) which is >ENGINE_R_CONFLICTING_ENGINE_ID. 0x72 (114) is the line number that has that ID in >crypto/engine/eng_list.c. > >So, this code path makes sense (to me) since if I break on the debugger, I see that >ENGINE_load_builtin_engines() is called twice since ssl_hook_pre_config is called >twice. 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. >Note that I can't reproduce this SEGV running under dbx, but can reproduce out of the >debugger (this trace is from a core). This leads me to believe that we are having a >double-init problem. > >Since pre_config doesn't get the process info, we can't use the userdata trick to >prevent double initialization. My solution would be to grow the pre_config hook to >get the process info. But, that can't be what was intended. =) -- justin 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. 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. Bill
