Re: configure openldap crash warning

I wrote:
> We still have a bit of work to do, because this setup isn't getting
> all the way through src/test/ldap/:
> 2022-05-04 11:01:33.459 EDT [21304] LOG: server process (PID 21312) was terminated by signal 11: Segmentation fault: 11
> Many of the test cases pass, but it looks like ldaps-related ones don't.

Sadly, this still happens with MacPorts' build of openldap 2.6.1.
I was able to get a stack trace from the point of the segfault
this time:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x000000018f120628 libsystem_pthread.dylib`pthread_rwlock_rdlock
frame #1: 0x00000001019174c4 libcrypto.3.dylib`CRYPTO_THREAD_read_lock + 12
frame #2: 0x00000001019099d0 libcrypto.3.dylib`ossl_lib_ctx_get_data + 56
frame #3: 0x00000001019144d0 libcrypto.3.dylib`get_provider_store + 28
frame #4: 0x000000010191641c libcrypto.3.dylib`ossl_provider_deregister_child_cb + 32
frame #5: 0x0000000101909748 libcrypto.3.dylib`OSSL_LIB_CTX_free + 48
frame #6: 0x000000010aa982d8 legacy.dylib`legacy_teardown + 24
frame #7: 0x0000000101914840 libcrypto.3.dylib`ossl_provider_free + 76
frame #8: 0x00000001018ec404 libcrypto.3.dylib`evp_cipher_free_int + 48
frame #9: 0x0000000101472804 libssl.3.dylib`SSL_CTX_free + 420
frame #10: 0x00000001013a4768 libldap.2.dylib`ldap_int_tls_destroy + 40
frame #11: 0x000000018f00fdd0 libsystem_c.dylib`__cxa_finalize_ranges + 464
frame #12: 0x000000018f00fb74 libsystem_c.dylib`exit + 44
frame #13: 0x0000000100941cb8 postgres`proc_exit(code=<unavailable>) at ipc.c:152:2 [opt]
frame #14: 0x000000010096d804 postgres`PostgresMain(dbname=<unavailable>, username=<unavailable>) at postgres.c:4756:5 [opt]
frame #15: 0x00000001008d7730 postgres`BackendRun(port=<unavailable>) at postmaster.c:4489:2 [opt]
frame #16: 0x00000001008d6ff4 postgres`ServerLoop [inlined] BackendStartup(port=<unavailable>) at postmaster.c:4217:3 [opt]
frame #17: 0x00000001008d6fcc postgres`ServerLoop at postmaster.c:1791:7 [opt]
frame #18: 0x00000001008d474c postgres`PostmasterMain(argc=<unavailable>, argv=<unavailable>) at postmaster.c:1463:11 [opt]
frame #19: 0x000000010083a248 postgres`main(argc=<unavailable>, argv=<unavailable>) at main.c:202:3 [opt]
frame #20: 0x000000010117908c dyld`start + 520

So (1) libldap relies on libssl to implement ldaps ... no surprise there,
and (2) something's going wrong in the atexit callback that it seemingly
installs to close down its SSL context. It's not clear from this whether
this is purely libldap's fault or if there is something we're doing that
sends it off the rails. I could believe that the problem is essentially
a double shutdown of libssl, except that there doesn't seem to be any
reason why PG itself would have touched libssl; this isn't an SSL-enabled
build. (Adding --with-openssl doesn't make it better, either.)

On the whole I'm leaning to the position that this is openldap's fault
not ours.

regards, tom lane