[gcc] Bug in emutls?

[Jakob Bohm]

On 18/11/2025 20:02, Jeremy Drake via Cygwin wrote:
> On Tue, 18 Nov 2025, Takashi Yano via Cygwin wrote:
>
>> 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?
> I remember working on this a while back, and adjusting the order that
> destructors are called to try to make it as correct as I could, but this
> last scenario was not fixable in the existing model.  LIU Hao actually
> made a new thread model for Win32/GCC largely to get all the destructors
> to run in the standards-compliant order.  Perhaps he can shed some light
> on what is supposed to happen here from the C/C++ standard side?
>
>>> 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.)
> This sounds like pthread_key destructors are not fit for purpose for
> running C++ destructors then, unless possibly used to register a single
> "meta-destructor" that runs the destructors in the proper order...  I
> think Cygwin would be better served with a different __cxa_thread_atexit
> implementation since the order of destructor calls is significant to the
> C++ standard.  Then it would be a matter of running those *before* the
> pthread_key destructors.

Implementation hint:

That cygwin is available only as a DLL provides an additional way to run
implementcleanup on orderly thread exit:  One of the last things that
happen in an orderly thread exit (ExitThread, returning from the thread
function etc.) is that Win32 entersa special start/stop global critical
section and then calls DllMain in cygwin1.dll with theDETACH_THREAD
value in the context of the exiting thread.  This provides a last chance
for the Cygwin runtime to do cleanups while the TLS slots of the thread
still exist.  Officially, some/many Win32 APIs are not allowed in that
critical section, mostly actions related to creating threads and/or
loading DLLs.  The historic Win16 WEP() entrypoint has similar but
stricter restrictions in what it could do during final cleanup.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded