On Mon, 17 Aug 2026, Rhialto wrote:
It is a long backtrace and it doesn't show the Python details, but here it is:
It actually explains everything. 1. Just the std. openssl EVP_*() funcs. are being used. (I was wondering who was using the obscure OPENSSL_LH_COMPFUNC(3) functions directly--it wasn't python3, I grepped the source.) 2. Note how the openssl path changes between frame #2 and frame #3 (and between #8 & #9 in the other backtrace). It started with an old openssl (bsd) and switched to the new one mid-stream. Ie. the apache2 crypto has not been inited anywhere, explaining why `lh->daaw' is NULL.
#0 0x0000000000000000 in ?? () #1 0x0000755703b0483f in doall_util_fn (arg=0x7f7fffeca0c0, wfunc_arg=0x0, func_arg=0x7557040072b1 <do_name>, func=0x0, wfunc=0x0, use_arg=1, lh=0x7557102e7df0) at /usr/src/crypto/external/apache2/openssl/dist/crypto/lhash/lhash.c:207 #2 OPENSSL_LH_doall_arg (lh=0x7557102e7df0, func=0x7557040072b1 <do_name>, arg=0x7f7fffeca0c0) at /usr/src/crypto/external/apache2/openssl/dist/crypto/lhash/lhash.c:230 #3 0x000075570400744e in lh_NAMENUM_ENTRY_doall_DOALL_NAMES_DATA (arg=0x7f7fffeca0c0, fn=0x7557040072b1 <do_name>, lh=<optimized out>) at /usr/src/crypto/external/bsd/openssl/dist/crypto/core_namemap.c:127 [...] The strange thing is that /usr/pkg/lib/python3.13/lib-dynload/_hashlib.so (frame #16) appears to be linked with /usr/lib/libcrypto.so.15, not 16, according to ldd.
Yes, this is classic library interpositioning--ie. a local issue. On Mon, 17 Aug 2026, Greg Troxel wrote:
But it seems with dlopen, and perhaps having multiple versions loaded, things are messy.
I would want to see Rhialto's: ``` ls -l /lib/crypto* /usr/lib/libcrypto* ``` -RVP
