DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5AHANgWL2952013
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 5AHANgWL2952013
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=xi5+Or+d
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 93B733858401
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1763375020;
	bh=5XcXduu6zUrWZ17FLhEB7VZq6X73mumWO6OGFafKCwE=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=xi5+Or+duo9QmyYpQYIuNZHmjmlxscaNJWzXmJY+vWSJsyZz/aZG9h9QF2sNrv3sK
	X3U0v+kE46yjdjvNugIS9yDX7AzZ/Dyf+MkIREOjHXXpewpBglsPk4ocjYAhoKv0mr
	J88ovaNN1nbZoqo/EEnXgsNSO0DfpXgUKnIj6QxY=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 4ECBB3858407
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 4ECBB3858407
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763374924; cv=none;
	b=QPJGbje+SQg5XGEpYVScd1wXpZmpV39QmGwKk30ZvYZKD+5OAlCQ4HTATpMFegGw4CGLVVMGFk7XU2dNQ95D4/DRcFRZThRiPl934rA0Pm2jh4v1wsX4HynDrruVoyDw/byMMpEOSQaAEw5e54RFDPxsPyb93VkOkxuQyOAcS0g=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1763374924; c=relaxed/simple;
	bh=bDwGpxh/o6oaZ+XHRG8CIw7S4dTMUm9ESEGsoOUMiJ4=;
	h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
	b=NM0nVDiSn8ZL32gFKbSUtdAvxQE3Y67cic3t8dhpn42RprinxtrqOEhRToDVyA6m64p/SCIr3pVLHwv9HE0CQKvwZFBjNlVyX1zlIbcAofmB6N3o8NrS+EX80ZqEH5moabLPL5FaGxltOwHQiCcuFPK5bsMoaiLkJgWtMmRk2Jk=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 4ECBB3858407
Date:	Mon, 17 Nov 2025 19:22:00 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: [gcc] Bug in emutls?
Message-Id:	<20251117192200.7c38aef3a4f46843d67f53e6@nifty.ne.jp>
In-Reply-To:	<20251108210156.20eadc80a8161eece6810175@nifty.ne.jp>
References:	<20251108210156 DOT 20eadc80a8161eece6810175 AT nifty DOT ne DOT jp>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
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:	Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
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>

Hi Achim,

On Sat, 8 Nov 2025 21:01:56 +0900
Takashi Yano via Cygwin <cygwin AT cygwin DOT com> wrote:
> Hi everyone,
> 
> I encountered a problem with static thread_local in C++ program.
> The following simple reproducer does not work as expected if it
> runs under cygwin 3.7.0 (Test), while it works under cygwin 3.6.5.
> 
> To conclude, this was not a bug in Cygwin 3.7.0.
> 
> This is triggered by the commit:
> commit ebd92b128f62a0b3c270319487b8486abdfa405b
> Author: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
> Date:   Fri Apr 4 21:22:27 2025 +0900
> 
>     Cygwin: thread: Use simple array instead of List<pthread_key>
> 
> where the call order of the destructors for pthread_key was changed.
> The call order can depend on implementation. So the code using
> pthread_key should not expect any predetermined call order of the
> destuctors.
> 
> The result of the following code is
> 1: 0xa00016938
> 2: 0xa00016b98
> X::print(): 2
> X::print(): 1
> X::~X(): 1
> X::~X(): 2
> under cygwin 3.6.5, while it is
> 1: 0xa00016938
> 2: 0xa00016b98
> X::print(): 2
> X::print(): 1
> X::~X(): 2133815816
> X::~X(): 2133815816
> under cygwin 3.7.0 (Test).
> 
> 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.
> 
> Any idea?
> 
> 
> #include <thread>
> #include <cstdio>
> #include <unistd.h>
> 
> class X {
> 	int n;
> public:
> 	X(int n1) : n(n1) {}
> 	~X() {
> 		printf("X::~X(): %d\n", n);
> 	}
> 	void print() {
> 		printf("X::print(): %d\n", n);
> 	}
> };
> 
> void func(int n) {
> 	static thread_local X x(n);
> 	printf("%d: %p\n", n, &x);
> 	usleep(10000);
> 	x.print();
> 	usleep(10000);
> }
> 
> int main() {
> 	std::thread t1(func, 1);
> 	std::thread t2(func, 2);
> 
> 	t1.join();
> 	t2.join();
> 
> 	return 0;
> }

Any idea?

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

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