Re: py313-tortoisehg-7.2.2 on NetBSD 11.0; mysterious segfault

[RVP <rvp%SDF.ORG@localhost>]

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