X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A0293858295
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1705835478;
	bh=5HTJuZoUKPIuZN/6oTxb4kEQbshsB0+3lEIzTaFqfdE=;
	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=QUNueHEEvxSp5oNHxjaYpMENbUfVN5fl6QvYsXIXkrqP+sgnfAcUF0wzkFlLkuWn7
	 IXEt3j0Q265le8i31abapq2SkDbcRa1tfdnSoZDpGmVVehTu1CjTzAEi0t0h9Np3fJ
	 TFL3z5QXRclMoevnYXt0XuTtiLDOXRGZq4aykm7I=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33BB33858C33
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 33BB33858C33
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705835457; cv=none;
 b=K79aVjsTjQ2ifEfJaBrOGBXbQyujokzkn8ohCjFY1qoOaI86iWB7F+zHCH+KPUxudT/tUCPAF+/F8jgLGVYbxrnAmlyLiN8+A5DOHuU3MhDs1TuanL1eq37G91N7kXRbwQ21eaGFD+TSVjZzJ8m8ITUf67yuD2Gf1lkx1Asp/Hs=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1705835457; c=relaxed/simple;
 bh=RuAYIrUV+WY+hphJLEVtDeRWW2O9yM0Z0AYFg+bKWog=;
 h=Date:From:To:Subject:Message-Id:Mime-Version;
 b=FOOyhCyIYOQe7Sa8rJu8I9/9yRwq7qSIYfQLayQhIVhI3mgktQb+/urHeXh3RTL1zdxmxOYlYWA1oBCgC5PFrczMyuCMT8Ik06BtmAE1C+HwPsHevGri/r5IIapSiZX9sXEWu9uUMQEpYikXTKSQs9zN+DXTk/JBCiGQquoJHDc=
ARC-Authentication-Results: i=1; server2.sourceware.org
Date: Sun, 21 Jan 2024 20:10:51 +0900
To: cygwin AT cygwin DOT com
Subject: Re: Possiblly bug of cygwin1.dll
Message-Id: <20240121201051.795a4405576a97ab8729e273@nifty.ne.jp>
In-Reply-To: <20240120212427.1e69fd3655ece73ecd508def@nifty.ne.jp>
References: <20240119224436 DOT 876a055f356f7c6796bc725b AT nifty DOT ne DOT jp>
 <ZaqHGElhXZIc3NFX AT calimero DOT vinschen DOT de>
 <20240120131825 DOT 4157c259fe058155137d6fe0 AT nifty DOT ne DOT jp>
 <20240120141349 DOT cde31e62177a0405b0ee9934 AT nifty DOT ne DOT jp>
 <87v87ov03x DOT fsf AT Gerda DOT invalid>
 <20240120212427 DOT 1e69fd3655ece73ecd508def AT nifty DOT ne DOT jp>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, 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.30
Precedence: list
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 Corinna,

On Sat, 20 Jan 2024 21:24:27 +0900
Takashi Yano wrote:
> On Sat, 20 Jan 2024 10:13:22 +0100
> ASSI wrote:
> > Takashi Yano via Cygwin writes:
> > > I might find the culprit in gcc's libstdc++ code such as:
> > > libstdc++-v3/include/ext/concurrentce.h:
> > >   class __mutex
> > >   {
> > >   private:
> > > #if __GTHREADS && defined __GTHREAD_MUTEX_INIT
> > >     __gthread_mutex_t _M_mutex = __GTHREAD_MUTEX_INIT;
> > > #else
> > >     __gthread_mutex_t _M_mutex;
> > > #endif
> > >
> > > __GTHREAD_MUTEX_INIT here is PTHREAD_MUTEX_INITIALIZER and
> > > __gthread_mutex_t is pthread_mutex_t.
> > >
> > > I think this code vaiolates the POSIX statement.
> > 
> > So what happens if you undefine __GTHREAD_MUTEX_INIT?
> 
> I have tried. The test case:
> #include <mutex>
> int main()
> {
>   for (;;) {
>     std::mutex *m = new std::mutex;
>     m->lock();
>     m->unlock();
>     delete m;
>   }
>   return 0;
> }
> gets working fine. However, this test case:
> #include <future>
> int func() { return 0; }
> int main()
> {
>   for (;;) {
>     std::future<int> f = std::async(std::launch::async, func);
>     f.get();
>   }
>   return 0;
> }
> still has the problem.
> 
> pthread_mutex_t might be initialized also at another place...

I found the cause. In pthread.h of cygwin, PTHREAD_ONCE_INIT is defined as:
#define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
however, libstdc++ initializes non-static pthread_once_t using this macro.

I cannot find the POSIX statement that only static pthread_once_t can be
initialized using PTHREAD_ONCE_INIT. If I do not overlook something,
this is the problem of cygwin side, isn't it?

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