DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 62HEvtkc994041
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 62HEvtkc994041
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=wA+VnRom
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org B0A574BBCDB6
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1773759473;
	bh=OhmpsjhdOgWwdapwMdtgZlBszpy49MRLGjKAwPa1VFg=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=wA+VnRomCAbbtxVokUFqF8MDQudbbNgsM9ScNeWDo/T7X/oNLKDNfPhE0UiBJ3n2/
	SQ3GzwUAMTDlLTIx01q/6noJ3N6sqvSRZgwqXigVeItBm0nKxJVbq7lE3Jb/zFTXr2
	p1tturUah6biZEeNWaPunjG6wZqH2+nRBh9w29Hk=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 0473F4BB591D
Date:	Tue, 17 Mar 2026 15:57:04 +0100
To:	cygwin AT cygwin DOT com
Subject:	Re: std::mutex bug: Windows handle growth
Message-ID:	<ablrwLuQANbPUmVi@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com, Noel Grandin <noelgrandin AT gmail DOT com>,
	Frank Eskesen <feskesen AT hvc DOT rr DOT com>
References:	<2d48a740-ce2b-4259-8947-f5c875dd1672 AT hvc DOT rr DOT com>
	<406b3882-15be-4d24-945c-42f1e2715e87 AT gmail DOT com>
	<ablgU3yUW0YI_QDf AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<ablgU3yUW0YI_QDf@calimero.vinschen.de>
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:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
	Noel Grandin <noelgrandin AT gmail DOT com>,
	Frank Eskesen <feskesen AT hvc DOT rr 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 Mar 17 15:08, Corinna Vinschen via Cygwin wrote:
> On Mar 17 09:06, Noel Grandin via Cygwin wrote:
> > Hi
> > 
> > Hazarding a guess here:
> > 
> > On 3/16/2026 11:39 PM, Frank Eskesen via Cygwin wrote:
> > > I've run into a problem that occurs on Cygwin that doesn't occur on Linux
> > > systems: When a std::mutex is used, it doesn't clean up a Windows handle that
> > > it uses. This sample program demonstrates the problem, failing in under 60
> > This code looks suspicious:
> > 
> >     pthread_mutex::destroy ()
> >     {
> >       if (condwaits || trylock ())
> >         // Do not destroy a condwaited or locked mutex
> >         return EBUSY;
> > 
> > I think it should be
> > 
> >       if (condwaits || !trylock ())
> 
> No, checking trylock() is correct.  pthread_mutex_destroy() must not
> destroy a busy mutex.  trylock() returns != 0 if the lock is busy.
> 
> Given the implementation of std::mutex is based on pthread_mutex,
> Frank's code is wrong, or at least somewhat borderline.  The mutex
> should first be unlocked before leaving do_something().
> 
> The reason this problem doesn't occur on Linux is the fact that mutexes
> are implemented without allocating a system object, so the
> pthread_mutex_destroy() function is basically a no-op, after checking if
> the lock is busy and returning 0 or EBUSY, whatever is right.

This looks like a bug in libstdc++ (trying with gcc 13.4.0).

I stepped through the do_something function, and what I can see is a
call to pthread_mutex_lock() from
std::lock_guard<std::mutex>::lock_guard() and a call to
pthread_mutex_unlock from std::lock_guard<std::mutex>::~lock_guard(),
but never a call to pthread_mutex_destroy().

I assume that the code in libstdc++ is using the underlying default
pthread code and simply assumes, that a destroy isn't required.


Corinna

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