On 08/03/2018 03:28 PM, Stefan Eissing wrote:
> (I am trying to understand this issue, since someone reported probs
> with mod_md/mod_ssl/some db drive init order related to openssl init.)
>
> The the move from cleanup() to pre_cleanup() fixed this issue. It means (as I
> read it)
> that something was happening in sub-pools cleanup()s that was out-of-order.
>
> Looking at apr_crypto_init(), it registers the cleanup at the "root" pool,
> does this give a clue?
>
> So we might have:
>
> - mod_ssl loading libssl, loading libcrypto
> cleanup at pool
> - ...
> - someone (indirectly) calling apr_crypto_init()
> cleanup at root pool
>
> root pool destroy:
> sub pool destroy
> -> mod_ssl cleanup called
> -> apr cleanup called
We have
1. ap_init_rng in main.c causes apr_crypto_init called with ap_pglobal
2. This causes apr__crypto_openssl_term to be registered as a cleanup with
ap_pglobal.
3. mod_ssl is loaded via the pconf pool which is a child of ap_pglobal
4. The loading of mod_ssl triggers the loading of libssl via the dynamic linker.
5. libssl is initialized in ssl_hook_pre_config via
SSL_load_error_strings();
SSL_library_init();
6. The above seems to cause references to static data in libssl being saved in
data structures
managed by libcrypto.
7. apr_pool_destroy(process->pool) in main.c:283 destroys the ap_pglobal which
in turn
a) first destroys pconf
b) which causes mod_ssl to be unloaded
c) which cause libssl to be unloaded
8. The cleanups of ap_pglobal are now called, especially
apr__crypto_openssl_term which
a) calls EVP_cleanup()
b) which tries to access the data stored in 6., but is gone since 7c)
Using a pre_cleanup moves 8. before 7. and thus removes the issue.
Regards
Rüdiger
