DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5AHJIp1Z3570457
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B44B43858C31
Date: Mon, 17 Nov 2025 11:16:41 -0800 (PST)
To: Takashi Yano <takashi.yano@nifty.ne.jp>
cc: cygwin@cygwin.com
Subject: Re: [gcc] Bug in emutls?
In-Reply-To: <20251108210156.20eadc80a8161eece6810175@nifty.ne.jp>
Message-ID: <10ce5538-1f7d-e1d8-71e2-64d63e5634b0@jdrake.com>
References: <20251108210156.20eadc80a8161eece6810175@nifty.ne.jp>
MIME-Version: 1.0
Precedence: list
From: Jeremy Drake via Cygwin <cygwin@cygwin.com>
Reply-To: Jeremy Drake <cygwin@jdrake.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

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

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?

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

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