DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5AIJ34s5888560
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 5AIJ34s5888560
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=J7vhdJk3
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 12821385AC20
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1763492583;
	bh=2cPk2vGQn30ToKjsAHib+TOzngKFMo4qNxiTBz/s2xc=;
	h=Date:To:cc:Subject:In-Reply-To:References:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	From:Reply-To:From;
	b=J7vhdJk3RdvUwakRgNRNfc8hHlJCey6UWL0TTIaRN5cNQy2xRCzppUbINrKW7NhQX
	rbpOIPpJ5lgDYbYlmgmLaouUeNyUaUAUxPWePRPFtblUT1ic0bn+CoOR+ahwfh4rjq
	kHohvUWxk5xiiGh+eQOtCROG0ghHAnIMFfzivCbE=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org BDB36385B511
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org BDB36385B511
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763492553; cv=none;
	b=JaK5AQPd+un6uBcD030mkWIlSK462yuJN1dnbhrXzBPXJ0V9gYRU9/eNZwGGAyPJlU1mOJzQylSZ2dZemfmqcVgebmIx2Trqy/lYBNfUizWg4nTKeuTTOztC664BueTNk3LH+HIk6rNzn9k/J3Fr5wCCrKmea/4dN1HMPVgsX14=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1763492553; c=relaxed/simple;
	bh=GTc5rBN5esUxEBM7FYyw+OUokZ3F2OQ8SX9Jo0SljZI=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=fnVN3kgd/VEcoVAPlmhUtThtPJQRyizz4V9Sms3/Ik+cano3TN4NTnT5OhFLycyahFCpc53mi3wAMPIpiK8Ir0oqDsKXBOcFCL84UFXdcc+1ubLHjuXb+PvJIsYyeRl+7sAleALO9Wxl6Lk5al58cQybgycoWKcg3g39E9TFOY0=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org BDB36385B511
Date:	Tue, 18 Nov 2025 11:02:32 -0800 (PST)
X-X-Sender:	jeremyd AT resin DOT csoft DOT net
To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
cc:	cygwin AT cygwin DOT com, LIU Hao <ltpmouse AT gmail DOT com>
Subject:	Re: [gcc] Bug in emutls?
In-Reply-To:	<20251118221047.9635f02cf9c77fe08993b6bd@nifty.ne.jp>
Message-ID:	<c3da1738-91fe-f21f-b4fa-da1e9bd65f62@jdrake.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>
MIME-Version:	1.0
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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:	Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jeremy Drake <cygwin AT jdrake DOT com>
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>

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.

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

- Raw text -