In BIND 9, it is possible to use a custom allocator that tracks the memory allocations. When enabled, the tracking reports unreleased memory after calling OPENSSL_cleanup():

add 0x7228000002a0 size 128 func isc__crypto_malloc_ex file crypto/sparse_array.c line 176 mctx 0x72b400014020
add 0x721000007c60 size 32 func isc__crypto_malloc_ex file crypto/sparse_array.c line 60 mctx 0x72b400014020
add 0x7218000008c0 size 56 func isc__crypto_malloc_ex file crypto/threads_common.c line 358 mctx 0x72b400014020

First pointer is the allocated memory, file and line comes from OpenSSL itself, the isc__crypto_malloc_ex() is just a thin wrapper around the malloc() and mctx is an internal structure for every memory context (tracking object).

This leaked memory is consistent both in the single and multithreaded programs and adding OPENSSL_thread_stop(); after thread exits doesn't really help.

The exit check is done in the program destructor (not library destructor, so the order of destructors is determinate).

There is a total 8109 allocations and only 8106 deallocations.