X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B041A3858430
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1706097345;
	bh=Le1XrNn6hZT2pa/Z16TktkxhNucnQe/LB01x7YwtE0U=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=Ol6dX5PLUd2aiiZMo/HYqB9Nx/7kA3M3wN95tzAqmKlga5WmyLEOwGkuzWUefM6Xk
	 Yam/c6b8+Jx00g2hdzOjWUmJuTrIHZseOtbxeFKClaLWbvsifglFLPvrf1OlYGhtFk
	 gd/P5gzZt0zup0OHjPFDjB3cio1IBFiBFadS4j08=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1E1913858D3C
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1E1913858D3C
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706097321; cv=none;
 b=i378RnstSalogCzFbigKNt7Y/tfCGQiw37hyWeXbAWk2rHPUXhfYJlgqQr2rFzIpVwfAz0J5H8YRAyBlzmGpkL4TMZ8a3xsE1aJGk92QYKz3fQIt6qNR7Qh8nTFhzfi7BC6KLzlfVJdOxZe7XYX5ma7BFGIWDHhlaVSXZmIGdfo=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1706097321; c=relaxed/simple;
 bh=ox0yKnPR+PAhkfJfRQFRER7K1/f8PUxHCWdAF8waoGM=;
 h=Date:From:To:Subject:Message-Id:Mime-Version;
 b=cRFAIdyh25NzE25ZTuukoN00Yv/DvW0g5l0hc6PGBRb6fGuTZidK3xChbu6Sp7TuYAqKi7kVg6Q5tLuybTdfGl4e4sgZi2TCrVAXxXA+yWla6si9YGj8qY1/OcMYbSEaCXkNjkicwwgKbHx/IzV2m8naVB551Xb0eSYNtacPpFE=
ARC-Authentication-Results: i=1; server2.sourceware.org
Date: Wed, 24 Jan 2024 20:55:14 +0900
To: cygwin AT cygwin DOT com
Subject: Re: Possiblly bug of cygwin1.dll
Message-Id: <20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp>
In-Reply-To: <c90e29238d7bb99ef6a8787f38585c21@kylheku.com>
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>
 <c90e29238d7bb99ef6a8787f38585c21 AT kylheku DOT com>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
X-Spam-Status: No, score=-4.0 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>

On Mon, 22 Jan 2024 19:24:52 -0800
Kaz Kylheku wrote:
> On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> > 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;
> > }
> 
> Note POSIX:
> 
> In cases where default mutex attributes are appropriate,
> the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize
> mutexes. The effect shall be equivalent to dynamic initialization
> by a call to pthread_mutex_init() with parameter attr specified as NULL,
> except that no error checks are performed.
> 
> Thus, the following is correct:
> 
>    for (;;) {
>      pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
>      pthread_mutex_lock(&m);
>      pthread_mutex_unlock(&m);
>      pthread_mutex_destroy(&m); // <--- added
>    }
> 
> Does your above code leak if you add the destroy call?

No.

> If so, pthread_mutex_destroy needs to be fixed.
> 
> Either way, libstdc++ should be calling pthread_mutex_destroy
> in the destructor, in spite of initializing the object with
> a simple initializer.

Are there any code examples that use PTHREAD_MUTEX_INITIALIZER
with pthread_mutex_destroy()?

> That libstdc++ library could be fixed in the same way;
> the mutex object's destructor should call pthread_mutex_destroy,
> even though the constructor didn't call pthread_mutex_init.
> 
> This is a "moral equivalent":
> 
>   class buf {
>     unsigned char *ptr;
>   public:
>     buf() : ptr(NULL) { }
>     ~buf() { delete [] ptr; }
>     // ...
>   };
> 
> Just because you have a constructor that trivially initializes
> some resource with a constant expression doesn't mean that the
> destructor has nothing to free. In between there the object
> is mutated so that it holds resources.
> 
> 
> > POSIX states pthread_mutex_t can be initialized with
> > PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.
> 
> I'm looking at this and don't see such a constraint:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html
> 
> The word "static" only occurs in the Rationale section.
> 
> Use of the initializer is not restricted to static objects
> by any normative wording.

It seems that I had read the older POSIX document.

https://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html

> In real systems, the static distinction has no meaning.
> 
> This code can be inside a shared library:
> 
>    static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> 
> this library could be loaded by dlopen and unloaded with dlclose.
> Thus static becomes dynamic!
> 
> And, by the way, this is a problem: if we have a library
> which does the above, and we repeatedly load it and unload
> it while using the mutex in between, it will leak.

As you pointed out, if dlopen()/dlclose() are called repeatedly,
handle leak might occur even if pthread_mutex_t is statically
allocated.

> I think you don't want to do this kind of initialization in
> reloadable plugins, unless you put in some destructor hooks,
> or wrap it with C++ objects with destructors.


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