DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5AJ529rb1411772
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 5AJ529rb1411772
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=hjNSBcTU
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFD7C384F022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1763528528;
	bh=MSAcYn0U/EovjR3TzqeKTDcT7TExwSACbkVUDZMGzL8=;
	h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=hjNSBcTUsyaiVp1pEWt9DzS36UcEjj7qDQh0vz6Q1MPHVG/IkTWySpTfJj7KWv9MA
	 29CuFz/t+KUfeFXAWjJEYzmN/+4gB60YKKqvHHaw2p7eGiYbzwbt5Tzeadwi3CQhpl
	 WTtmrc0UAflTq2o0LC7Wm4pxJgZBrJoEafmZpFQQ=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA3F8384F002
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CA3F8384F002
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763528455; cv=none;
 b=RmEUpVQbk8kMepg4OSH0EjfsnM/+LK8hbuu5VcDZ+KN5ZFrMA8k/razFxpq8a+qlAUF4pceG5zkHfMtdKu6cyezoDbK6u2i1jzKf3UGzMmX9qvKItrYU4f9J4pSMNM9GeF6x2F2f5MQlylSQh6fiJQvyrlYhb/J7M+oRSPTl50o=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1763528455; c=relaxed/simple;
 bh=11u4m195WXC7aGdbXRK4fu9vkGqly+nHj+VhGI+2t/Q=;
 h=DKIM-Signature:Subject:To:From:Message-ID:Date:MIME-Version;
 b=i68Sq7YwzaO31cG+cHt/undo74ZjwN5FQQJPlbf1VOG1fkne4VEIFeMBznAX7qrfJw8vgug9NuLuhshWFruViNcHe+Gz1r+DeSq0tWx/ai9ZL9bo5ZqQthQQI8z2GavM5o+MwDQFhX2Repoa5chvoPwD1SmMLcfYgGndnWPs4pQ=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA3F8384F002
Subject: Re: [gcc] Bug in emutls?
To: cygwin AT cygwin DOT com
References: <20251108210156 DOT 20eadc80a8161eece6810175 AT nifty DOT ne DOT jp>
 <10ce5538-1f7d-e1d8-71e2-64d63e5634b0 AT jdrake DOT com>
 <20251118221047 DOT 9635f02cf9c77fe08993b6bd AT nifty DOT ne DOT jp>
 <c3da1738-91fe-f21f-b4fa-da1e9bd65f62 AT jdrake DOT com>
Organization: WiseMo A/S
Message-ID: <b8c427bf-cdf4-8fe6-02d4-6fc73c2e3ee7@wisemo.com>
Date: Wed, 19 Nov 2025 06:00:55 +0100
X-Mailer: Epyrus/2.1.3
MIME-Version: 1.0
In-Reply-To: <c3da1738-91fe-f21f-b4fa-da1e9bd65f62@jdrake.com>
Content-Language: en-US
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Jakob Bohm via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jakob Bohm <jb-cygwin AT wisemo DOT com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 5AJ529rb1411772

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


-- 
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