(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? -Stefan > Am 03.08.2018 um 14:50 schrieb Ruediger Pluem <[email protected]>: > > > > On 08/03/2018 12:45 PM, Yann Ylavic wrote: >> On Fri, Aug 3, 2018 at 11:46 AM, Ruediger Pluem <[email protected]> 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
