Hi Jeremy, On Mon, 17 Nov 2025 11:16:41 -0800 (PST) Jeremy Drake wrote: > On Sat, 8 Nov 2025, Takashi Yano via Cygwin wrote: > > > I looked into the problem, and found that the executable for > > the following code registers two pthread_keys with each destructor; > > one is void emutls_destroy(void *ptr) in libgcc/emutls.c, and the > > other is void run(void *p) in libstdc++-v3/libsupc++/atexit_thread.cc. > > emutls_destroy() free's the memory erea of static thread_local X, > > that is accessed from X::~X() which is called from run(). As a result, > > if the emutls_destroy() is called before run(), run() referres to > > the memory erea already free'ed. > > > > I think this is a bug of gcc. This issue does not occur in Linux, > > because Linux does not use emutls. > > > There is a similar longstanding issue in mingw-w64. The problem there is > that the pthread_key destructors run before the native Windows TLS > callbacks. emutls still uses pthread_key to manage static thread_locals, > but C++ destructors are called from the Windows TLS callbacks (by way of > __cxa_thread_atexit if memory serves).
Thanks for the information. When I compile my reproducer with mingw compiler, the issue does not seem to happen. How does mingw handle this issue? > Cygwin should have it comparatively easy: it controls all the pieces (it > doesn't need to care about when Windows TLS callbacks happen because if > somebody calls ExitThread they get the undefined behavior they deserve). > Couldn't Cygwin simply provide its own __cxa_thread_atexit and ensure > destructors registered there run before pthread_key destructors? It is not difficult to add a workaround for this issue in cygwin side. However, IIRC, BSD libc does the same with cygwin 3.7.0-dev. I don't think it is good idea to add workaround to cygwin for a bug of apps on cygwin. > Regardless, is it really undefined in what order pthread_key destructors > run? I would expect they'd run in reverse order of registration (most > recently registered first). Wouldn't that prevent this issue too > (without mucking about with the Itanium C++ ABI)? https://pubs.opengroup.org/onlinepubs/9799919799/ says: "The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits." As you expected, the reverse-order'ed destructor-call hides the issue. (That is what 3.6.5 does.) -- Takashi Yano <[email protected]> -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
