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
Content-Disposition: inline
In-Reply-To: <ablgU3yUW0YI_QDf@calimero.vinschen.de>
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: 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>
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>

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