SIGSEGV on exit on cygwin

[Berrysoft]

I did this

It's hard to get a MWE. I'll discribe what I've done:

• I'm the maintainer of cygwin target of rust, and recently I've managed to compile cargo targeting MSYS2 (a variant of cygwin), linking libcurl 8.13.0 and openssl 3.5.0 (dynamically).
• cargo fail silently with SIGSEGV on an anoymous thread exits. Backtrace:

#0  0x0000000000000000 in ?? ()
#1  0x00000001800b2827 in pthread_testcancel () at /d/S/B/src/msys2-runtime/winsup/cygwin/thread.cc:399
#2  pthread_rwlock_wrlock (rwlock=0xa000b73b0) at /d/S/B/src/msys2-runtime/winsup/cygwin/thread.cc:4352
#3  0x000000018019ce44 in _sigfe () at sigfe.s:35
#4  0x0000000435849299 in CRYPTO_THREAD_write_lock () from /usr/bin/msys-crypto-3.dll
#5  0x0000000435835702 in init_thread_remove_handlers () from /usr/bin/msys-crypto-3.dll
#6  0x0000000435835b43 in OPENSSL_thread_stop () from /usr/bin/msys-crypto-3.dll
#7  0x00000005d24bbfdd in DllMain (hinstDLL=<optimized out>, fdwReason=<optimized out>, lpvReserved=<optimized out>) at dllmain.c:74
#8  0x00007ff869351e53 in ntdll!RtlDeactivateActivationContext () from /c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x00007ff8692f2294 in ntdll!LdrShutdownThread () from /c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x00007ff8692f1da6 in ntdll!RtlExitUserThread () from /c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x00000001800c4eb0 in exit_thread (res=res@entry=0) at /d/S/B/src/msys2-runtime/winsup/cygwin/sigproc.cc:587
#12 0x00000001800ab540 in pthread::exit (this=0xa001e6b60, value_ptr=0x0) at /d/S/B/src/msys2-runtime/winsup/cygwin/thread.cc:584
#13 0x00000001800ab333 in pthread::thread_init_wrapper (arg=0xa001e6b60) at /d/S/B/src/msys2-runtime/winsup/cygwin/thread.cc:2016
#14 0x0000000180044841 in pthread_wrapper (arg=<optimized out>) at /d/S/B/src/msys2-runtime/winsup/cygwin/create_posix_thread.cc:79
#15 pthread_wrapper (arg=<optimized out>) at /d/S/B/src/msys2-runtime/winsup/cygwin/create_posix_thread.cc:39

• It turns out that a thread exits and libcurl is detached. It calls OPENSSL_thread_stop and crashes.
• So I looked into the source code and the comment says that it is for statically linked openssl, so I removed this call and compiled again. Now cargo works fine.

I expected the following

Well, as it's very hard to construct a MWE, I'm asking experts for help. Could someone explain that whether it is necessary to call OPENSSL_thread_stop if openssl is dynamically linked?

Or, could someone help me to get the clue that, why libcurl is detached when cargo is running?

curl/libcurl version

curl 8.13.0

operating system

MSYS2

[jay]

Could someone explain that whether it is necessary to call OPENSSL_thread_stop if openssl is dynamically linked?

Ref: openssl/openssl#22831
Ref: #12408
Ref: https://github.com/curl/curl/blob/curl-8_13_0/lib/dllmain.c#L45-L81

The function is effectively idempotent and it's supposed to be safe to call it multiple times. If OpenSSL is its own DLL (like in this case) then it calls the function beforehand and if it's a static library then it doesn't. The function should be called at least once per thread to prevent a memory leak. We make a call regardless and I think that was because we don't know if OpenSSL is part of the current module (like whether OpenSSL is its own DLL or part of some other DLL like libcurl or a DLL that contains static libcurl and static openssl).

[Berrysoft]

So, I assume that it's OK to not call this method in my case?

[Berrysoft]

OK, seems that it's an openssl bug: msys2/MSYS2-packages@5c5fb0c

Thank you very much. I'll ask MSYS2 to disable this call for libcurl.

[jay]

If it is a bug in OpenSSL why wasn't it sent upstream? There are no other reports of it being a problem. Is it possible this is just msys2 specific?

/cc @lazka

[Berrysoft]

https://cygwin.com/pipermail/cygwin/2011-March/194454.html

It's interesting that the patch has been sent to the mailing list of openssl in 2008, but no one replied.

[lazka]

Yeah, we should report this upstream, and once fixed curl likely needs do apply a similar fix.

As to why it's not a problem in cygwin proper, I don't know. It only crashed for us in some cases, so maybe it depends on the usage pattern.

[BrianInglis]

Local patch applied by Cygwin OpenSSL maintainer to test release; see Test: openssl 3.0.16-2, mingw64-{i686,x86_64}-openssl-3.0.16-2 and
openssl and libcurl issue with cargo

[jeremyd2019]

Yeah, we should report this upstream, and once fixed curl likely needs do apply a similar fix.

As to why it's not a problem in cygwin proper, I don't know. It only crashed for us in some cases, so maybe it depends on the usage pattern.

I am seeing this same problem in cygwin proper. It seems like it really shouldn't be trying to run this cleanup function from DllMain on Cygwin, as the pthread stuff has already been shut down by then, and openssl appears to be using a pthread_key_create destructor to do the cleanup anyway (and that would have already been completed by the time DllMain is run)