[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svn commit: r1198930 - in /httpd/httpd/trunk: include/mod_core.h server/core.c server/main.c

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
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.