public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Cc: ASSI <Stromeko@nexgo.de>
Subject: Re: Possiblly bug of cygwin1.dll
Date: Sat, 20 Jan 2024 14:13:49 +0900	[thread overview]
Message-ID: <20240120141349.cde31e62177a0405b0ee9934@nifty.ne.jp> (raw)
In-Reply-To: <20240120131825.4157c259fe058155137d6fe0@nifty.ne.jp>

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.yano@nifty.ne.jp>

  reply	other threads:[~2024-01-20  5:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 13:44 Takashi Yano
2024-01-19 14:28 ` Corinna Vinschen
2024-01-20  4:18   ` Takashi Yano
2024-01-20  5:13     ` Takashi Yano [this message]
2024-01-20  9:13       ` ASSI
2024-01-20 12:24         ` Takashi Yano
2024-01-20 12:46           ` ASSI
2024-01-21 11:10           ` Takashi Yano
2024-01-21 13:30             ` ASSI
2024-01-22  3:30               ` Takashi Yano
2024-01-22  9:25                 ` Corinna Vinschen
2024-01-22  9:57                   ` Corinna Vinschen
2024-01-22 11:16                     ` Takashi Yano
2024-01-22 11:49                       ` Corinna Vinschen
2024-01-22 12:41                         ` ASSI
2024-01-22 14:54                           ` Corinna Vinschen
2024-01-22 11:06                   ` Takashi Yano
2024-01-22 11:42                     ` Corinna Vinschen
2024-01-23  3:24     ` Kaz Kylheku
2024-01-24 11:55       ` Takashi Yano
2024-01-24 13:05         ` Corinna Vinschen
2024-01-24 13:11           ` Corinna Vinschen
2024-01-24 20:37             ` Kaz Kylheku
2024-01-24 20:08         ` Kaz Kylheku

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240120141349.cde31e62177a0405b0ee9934@nifty.ne.jp \
    --to=takashi.yano@nifty.ne.jp \
    --cc=Stromeko@nexgo.de \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).