X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 484A13857C51
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1687265622;
	bh=taUJkqBKd+lsY7Z4z1cFgWGhIgbIR8RPLESkK0ItV60=;
	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=ixODq2kGdNGMmcTKclfac18yzUOu/8Pq672zFUIlrzg2D/SWyP1sbqjInxi6+6xCo
	N5Fjn+gDCMpEwaJHaiJ0jhk/4HZquYHD0u5CgzdW4wUOP0eui4zXTfbev7+UfL47j2
	RFU3Q+1kwwtOSDCoGBCbFhkPcI8ghebQSYnw7gYk=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 53CF53858D1E
Date:	Tue, 20 Jun 2023 21:53:00 +0900
To:	cygwin AT cygwin DOT com
Subject:	Re: Memory Barriers at pthread using CYGWIN
Message-Id:	<20230620215300.def2e786b8fdce10b6317381@nifty.ne.jp>
In-Reply-To:	<1503743851.9556.1686370084334@aps7mgn-06>
References:	<CAPxKPA6zdV5UUdwcnhk9Sw159UQfVSsMjoiC4Sx3w-ojzw9Biw AT mail DOT gmail DOT com>
	<CAPxKPA48sKPqwGc-jU7UQvQhsbT0N6A9LJXCAZeaa1rjeRtuNg AT mail DOT gmail DOT com>
	<96718c68-af84-45a5-9332-337ec4b2f04a AT email DOT android DOT com>
	<CAPxKPA6bRfF19pXrYT04TqbxettyYf=ypgfdySysqAJyB9BfxA AT mail DOT gmail DOT com>
	<64831a27 DOT 170a0220 DOT 1f805 DOT 81bfSMTPIN_ADDED_BROKEN AT mx DOT google DOT com>
	<1503743851 DOT 9556 DOT 1686370084334 AT aps7mgn-06>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version:	1.0
X-Spam-Status:	No, score=-10.2 required=5.0 tests=BAYES_00, GIT_PATCH_0,
	KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS,
	TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
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>

On Sat, 10 Jun 2023 13:08:04 +0900 (JST)
Takashi Yano wrote:
> "M?min A." wrote:
> > //windows cmd line
> > C:\cygwin64\home\maydin\test>cygcheck ./main.exe
> > C:\cygwin64\home\maydin\test\main.exe
> >   C:\cygwin64\bin\cygwin1.dll
> >     C:\WINDOWS\system32\KERNEL32.dll
> >       C:\WINDOWS\system32\ntdll.dll
> >       C:\WINDOWS\system32\KERNELBASE.dll
> > 
> > C:\cygwin64\home\maydin\test>ldd ./main.exe
> >         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffa92350000)
> >         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> > (0x7ffa90570000)
> >         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> > (0x7ffa8ffb0000)
> >         cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffa27960000)
> 
> Looks OK.
> 
> > //When cygwin terminal closed and cmd line command. Join throw fails.
> > C:\cygwin64\home\maydin\test>main.exe
> > Failed to join the thread t1.
> > Failed to join the thread t2.
> > r1 = 1, r2 = 1
> > 
> > //when cygwin terminal opened. The test is passed.
> > C:\cygwin64\home\maydin\test>main.exe
> > r1 = 1, r2 = 1
> > 
> > 
> > I think Cygwin terminal should be always open in order to execute a file in
> > windows. Am I right ?
> 
> It should not be. Weird enough.
> 
> Could you please provide a strace log file such as:
> strace -o faild.log ./main.exe
> ?

I looked into this problem, and I think this is a problem regarding
_my_tls initialization order, so far. This seems to happen in LDAP
environment.

My assumption is:

If the program is the first program which load cygwin1.dll, ldap
connection seems to be made before pthread::init_mainthread().
In cyg_ldap.cc, cyg_ldap::connect(), cyg_ldap::search() or
cyg_ldap::next_page() calls cygwait() in which pthread::self()
is called.

Then, _my_tls.tid is initialized with null_pthread, therefore,
_my_tls.tid is not set in pthread::init_mainthread().

This causes pthread_join() failure at:
winsup/cygwin/thread.cc: line 2196
   if (!is_good_object (&joiner))
     return EINVAL;


The first idea to fix this issue is remove set_tls_self_pointer()
call from pthread::self().

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 5c1284a93..a0f2d5546 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -392,10 +392,7 @@ pthread::self ()
 {
   pthread *thread = _my_tls.tid;
   if (!thread)
-    {
-      thread = pthread_null::get_null_pthread ();
-      thread->set_tls_self_pointer ();
-    }
+    thread = pthread_null::get_null_pthread ();
   return thread;
 }
 

The secnd approach is to re-initialize _my_tls.tid in
pthread::init_mainthread() if _my_tls.tid is null_pthread.

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 5c1284a93..f614e01c4 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -364,7 +364,7 @@ void
 pthread::init_mainthread ()
 {
   pthread *thread = _my_tls.tid;
-  if (!thread)
+  if (!thread || thread == pthread_null::get_null_pthread ())
     {
       thread = new pthread ();
       if (!thread)


Which is the better approach, do you think?
Or any other 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 -