DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 59UBmF9Q2328651
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 59UBmF9Q2328651
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=EP8Zc9uW
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org F2F823858CD1
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1761824894;
	bh=/tTmCGyqesbXIyAx9vrf2+/t8o5LW9xXovXUPAucmaE=;
	h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post:
	List-Help:List-Subscribe:From:Reply-To:From;
	b=EP8Zc9uWcnLuV09bpaK7IEhIp2aVIJ3vYTFt43ps68XOmv0idMKBtQrB0Yoc7fH28
	gjnLELvHox/pXFCe/+W1lBYTyrlecVhaxBvamsPkToOagsqJacbajxm7MBVBSiANf/
	iy6CFUf5LBvsEZcslFN4hstgiX4w9qqCUFWJYuy4=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 3A5523858D2A
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 3A5523858D2A
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1761824829; cv=none;
	b=xVRQUhGbuRRrRXLkBb62tiOeDBDjcsZ3+Y0oV3a0wUwOdnsOKYaiK8OPVl6SBOKZV4r3IV009ZEvhIqZ9glgJjXDN8b+nldY57blJsECZTSrBlcofVOxJnyjskMSnzQrVIwW0HzqE7UMrSsuQgcKkgRjHkKROC7/DCFxyquhA18=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1761824829; c=relaxed/simple;
	bh=akliF0xzfWhPp7z2BVBArqom7oxuUmYJJpgJO/nnh0w=;
	h=Message-Id:From:To:Subject:Date:MIME-Version:DKIM-Signature;
	b=UvzgdqM9L9gYOduumWzI+ugFa1l8vDH/yPDXuaj1LlLVwewI7jHXFBnnStMVMYHGlizFxzIMzz3W/rVZZY2OCy3TbdpRKV+zNB/Jjl+BvW6BEchbbVl8/qE5oou+10B40NNbEFal8y8X1F2Yw7ccPuDqU0mhV2BA/inKG15S4zM=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 3A5523858D2A
Message-Id:	<1761818755428.1050851142.2466019548@ezweb.ne.jp>
To:	cygwin AT cygwin DOT com
Subject:	Deadlock in cygwin1.dll when joining a thread before thread_local
	initialization
Date:	Thu, 30 Oct 2025 11:47:05 +0000
X-Mailer:	Vivaldi Mail
User-Agent:	Vivaldi Mail/7.6.3797.63
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-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:	Tomohiro Kashiwada via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Tomohiro Kashiwada <tomohiro-kashiwada AT ezweb DOT ne DOT jp>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

------sinikael-?=_1-17618248255950.4033030765522001
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,


I found a deadlock in cygwin1.dll that occurs during process cleanup.

It happens when the following conditions are met:
- A thread is launched that will initialize the thread_local slot for a 
variable whose destructor is non-trivial.
- The main thread waits to join that thread during global destructor calls, 
before the thread has initialized the thread_local slot.

The former condition refers to a function-scope static thread_local 
variable, or a global thread_local variable whose name has not yet been 
referenced by any thread.

Here is a reproducer (the same file is attached), compile with g++ 13.4.0 
regardless of optimization, and run under cygwin 3.6.5-1
---------------------------------------------

#include <thread>

struct the_type {
   ~the_type() {}
};
struct myjthread {
   template <typename F>
   myjthread(F f): thr(f) {}
   ~myjthread() { thr.join(); }
   std::thread thr;
};

thread_local the_type g_v;


int main() {
   // if main thread accesses the thread_local variable first, pattern2 
doesn't matter
   //g_v = {};
   static myjthread t([] {
     //std::this_thread::sleep_for(std::chrono::seconds(1)); //< this sleep 
might increase reproducibility

     // pattern1: static thread_local
     static thread_local the_type s_v;

     // pattern2: global thread_local; its slot is allocated in this thread
     //g_v = {};
   });
}

---------------------------------------------

This issue was observed as a random hang in the LLVM test suite.

Although the triggering thread_local variable in LLVM can be removed, I 
hope the runtime can be fixed.

Regards,

--
Tomohiro Kashiwada (@kikairoya)


------sinikael-?=_1-17618248255950.4033030765522001
Content-Type: text/plain
Content-Disposition: attachment; filename=hang-static-thread-local.cc
Content-Transfer-Encoding: quoted-printable

#include <thread>

struct the_type {
  ~the_type() {}
};
struct myjthread {
  template <typename F>
  myjthread(F f): thr(f) {}
  ~myjthread() { thr.join(); }
  std::thread thr;
};

thread_local the_type g_v;

int main() {
  // if main thread accesses the thread_local variable first, pattern2 =
doesn't matter
  //g_v =3D {};
  static myjthread t([] {
    //std::this_thread::sleep_for(std::chrono::seconds(1)); //< this sleep =
might increase reproducibility

    // pattern1: static thread_local
    static thread_local the_type s_v;

    // pattern2: global thread_local; its slot is allocated in this thread
    //g_v =3D {};
  });
}

------sinikael-?=_1-17618248255950.4033030765522001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


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

------sinikael-?=_1-17618248255950.4033030765522001--

- Raw text -