DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5AHJIp1Z3570457
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 5AHJIp1Z3570457
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=RIINK5ec
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org A49E0385802C
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1763407130;
	bh=pCrvF7T780VU7XgKrfzqRBsQhluNIkbo41jrhtwRaiE=;
	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=RIINK5ec+/GReIEqNPUV6qAAfjLHvMw9EtyTkfhvRJTP0zpMlYh7N4CgfJIqnUSUG
	P7SyChMR88rZ9/6rcBWaP8Kr4WX2SdmAsLRAMB72qERnvV86Mhd9QgySVmko9ajhkw
	rWL49yaSP8F6dDTD3PYaIFHpVBnytPUER4xBFjOA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org B44B43858C31
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org B44B43858C31
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763407001; cv=none;
	b=Npf4DCF15VUshR3AK60AmcdWNtY0hJqygjQI9mJHN0R2B4O+aITotgeFZUMfbi35zPae2D08CBTCjTXxj1+3pN5xxKmMt7THHsPVX+NeK+U150NdTmgrmgPgyu0TZQJGd7f4ikRrltbh9+3jsNcbrE/h9toSHOrvtFL03d0Yswk=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1763407001; c=relaxed/simple;
	bh=0V8zyjx1ZYvRPAqO/rgNAqYXGrF3wTZIAWa0HewRH9U=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=lxQ7D7y9J8KwrFFIXocZKsSZ6AAltZhrdXqMwiDHWkxMew3TMcD2OqzHKAx+QIajwepTRtsGlSwvuKA/nwCMg60DybtM1irweuW7SKpYlQWN0Q+sPo1ETBSZ0EpIc5pNbh7p3Ni/pUVjw28g7EEZHTfs0zctRLkznpNGpkXEm4Q=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org B44B43858C31
Date:	Mon, 17 Nov 2025 11:16:41 -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
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 DOT 20eadc80a8161eece6810175 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 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

- Raw text -