X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8DDE1385840D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1705727657;
	bh=SPkm7Q6hiimQbHKSA2SQWdDR30E3WkQuKNfs/QYDnPw=;
	h=Date:To:Cc:Subject:In-Reply-To:References:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From:Reply-To:From;
	b=BioHTimhxpK/1opwt6BqmctksvHG1EtfK4wosq8f4B6TQzWOX0sB2i5oUgFjo2PU+
	 ap9l+AECfAqrD/QjpFucnfnagTiaQMP+rCCxIy/WCHgw7sxMt0EvH5RNHgcDk77SBN
	 qy9s3EhhZ4CJG3RSxxFMFJbq7jb4ulY3HIuxPQok=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABCF43858D3C
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ABCF43858D3C
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705727635; cv=none;
 b=Q/FXUA60x6UJ5g6YFHSZWOb3b71Npy22beYklngUt2nXX7S8RwA8i0PnP5QAgoUDmrKttSzhRNFQE0QtprVB2i7VsCoJSx2fD6zF4XWM0oX3JAtZaLyicgkOoJMfd+63CExUTYZuQ7XRLcrptrRSKVTA3X+6wrh9+np4xt8rmws=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1705727635; c=relaxed/simple;
 bh=qw6cnAs23SWj3wE50RaNNsrtpDlxHt8eLxmhocpST8s=;
 h=Date:From:To:Subject:Message-Id:Mime-Version;
 b=TYg6WOu8XviWU8SQ4h3v+K+cghg64ioM5mOImvnQAwesGTof2BS2UxIxV1t8P0bZV4GlWpgF3uBtFIKx0iIJu9l+A1c/JiNNUmsw9qzlg95b+6i4JDQmvZva0nvCsmzo6ypvX15bS+TZD4SRiAVrLRpgEVdZdIqp3Qn/tzKYap4=
ARC-Authentication-Results: i=1; server2.sourceware.org
Date: Sat, 20 Jan 2024 14:13:49 +0900
To: cygwin AT cygwin DOT com
Cc: ASSI <Stromeko AT nexgo DOT de>
Subject: Re: Possiblly bug of cygwin1.dll
Message-Id: <20240120141349.cde31e62177a0405b0ee9934@nifty.ne.jp>
In-Reply-To: <20240120131825.4157c259fe058155137d6fe0@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>
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 and Achim,

On Sat, 20 Jan 2024 13:18:25 +0900
Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 19 Jan 2024 15:28:40 +0100
> Corinna Vinschen wrote:
> > On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> > > Hi,
> > > 
> > > I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> > > The following test case (c++ code) causes handle leak.
> > > 
> > > This issue is reproducible with both g++ and clang++.
> > > However, it does not happen in Linux environment.
> > > So I guess this is the cygwin1.dlll bug.
> > > 
> > > I looked into this problem a bit, and found number of event handle
> > > increases every loop.
> > > 
> > > I doubt pthread_mutex_xxx functions.
> > > 
> > > #include <future>
> > > int func() { return 0; }
> > > int main()
> > > {
> > >   for (;;) {
> > >     std::future<int> f = std::async(std::launch::async, func);
> > >     f.get();
> > >   }
> > >   return 0;
> > > }
> > 
> > Can you create a plain C testcase from there?  It's much easier to
> > debug.
> 
> I could symplify the test case:
> #include <mutex>
> int main()
> {
>   for (;;) {
>     std::mutex *m = new std::mutex;
>     m->lock();
>     m->unlock();
>     delete m;
>   }
>   return 0;
> }
> 
> And I tried to observe the pthread_mutex_xxx() call. Then found the
> test case does like:
> 
> #include <pthread.h>
> int main()
> {
>   for (;;) {
>     pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
>     pthread_mutex_lock(&m);
>     pthread_mutex_unlock(&m);
>   }
>   return 0;
> }
> 
> POSIX states pthread_mutex_t can be initialized with
> PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.
> 
> In this case, m is not static. So it seems that this is
> a bug of libstdc++. However, the plain c code above works
> in Linux without problems even with non-static mutex m.
> 
> I guess it is very difficult to make the plain c code above
> work in cygwin, because cygwin can not know when cygwin can
> discard the mutex resources...

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.

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