From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta0007.nifty.com (mta-snd00012.nifty.com [106.153.226.44]) by sourceware.org (Postfix) with ESMTPS id ABCF43858D3C for ; Sat, 20 Jan 2024 05:13:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABCF43858D3C Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ABCF43858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=106.153.226.44 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 Received: from HP-Z230 by dmta0007.nifty.com with ESMTP id <20240120051350687.TVRS.1140.HP-Z230@nifty.com>; Sat, 20 Jan 2024 14:13:50 +0900 Date: Sat, 20 Jan 2024 14:13:49 +0900 From: Takashi Yano To: cygwin@cygwin.com Cc: ASSI Subject: Re: Possiblly bug of cygwin1.dll Message-Id: <20240120141349.cde31e62177a0405b0ee9934@nifty.ne.jp> In-Reply-To: <20240120131825.4157c259fe058155137d6fe0@nifty.ne.jp> References: <20240119224436.876a055f356f7c6796bc725b@nifty.ne.jp> <20240120131825.4157c259fe058155137d6fe0@nifty.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 List-Id: 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 > > > int func() { return 0; } > > > int main() > > > { > > > for (;;) { > > > std::future 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 > 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 > 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