[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

(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.
> Regards
> Rüdiger