Re: svn commit: r1198930 - in /httpd/httpd/trunk: include/mod_core.h server/core.c server/main.c
(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
with the fix reverting the cleanup order? Is that what's happening?
> Am 03.08.2018 um 14:50 schrieb Ruediger Pluem <rpluem@xxxxxxxxxx>:
> On 08/03/2018 12:45 PM, Yann Ylavic wrote:
>> On Fri, Aug 3, 2018 at 11:46 AM, Ruediger Pluem <rpluem@xxxxxxxxxx> wrote:
>>>> + ap_init_rng(ap_pglobal);
>>> With APR trunk used this now causes httpd to SEGFAULT in EVP_cleanup
>>> when it stops in case mod_ssl is loaded. This is because mod_ssl
>>> stored data in Openssl data structures that points to it (likely
>>> static data in mod_ssl), but it gets unloaded due to the pconf pool
>>> cleanup before the crypto_lib_cleanup runs EVP_cleanup as it is a
>>> cleanup on the parent pool ap_pglobal.
>> Ouch, ISTM that mod_ssl should cleanup what it owns after itself.
>> Any idea which static data (or code/callbacks) in mod_ssl are still pointed to?
> The static data referenced here is in libssl. So libssl gets unloaded because mod_ssl gets unloaded,
> libcrypto stays as we have it linked to APR. So we get caught by some internal referencing
> between libssl and libcrypto. So probably the crypto part of APR needs to load libssl as well.