X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D5E413858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1705980320;
	bh=Ar1TkcCS7R2WRelxnq6U7TMcc6Kxm7l4sIkcDZzt7f0=;
	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=l54cNwa6+z5pbGdp7d/oKE5C32Pd/G8EszmU7p7lu6qST+41DSWPG0SG/EpETp6ow
	 vbfojh/8msLnvsasS36EvjPZ2ejQ4KeoDj90RgdSsKKyLIINZ4A2u9h+e5mUhqBNzj
	 UCpXNeXrjmrcY03KhFwpnrvkmazsg+5HK9cdoqLs=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9DAD73858D20
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9DAD73858D20
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705980298; cv=none;
 b=MDnrU19u/Uie6iW2FpAtu6SyRWUdM7ZeiknbLVZYBm83Hg641rDgvtu4GuExZJ0mJO3pnvt+TZNO9jdqe3M39ZfaaFyPzQXjlfkL2vammMHtCHs4GungU40aWhTO0Tcx29d3PSCkDf86iwkGwLzZbOTAbbcnGfZiqRKRs6DS3j0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1705980298; c=relaxed/simple;
 bh=XUkapy+3tdNcNGGhnCRLFHIzzB8nRsSpXormm0AM4tg=;
 h=DKIM-Signature:MIME-Version:Date:From:To:Subject:Message-ID;
 b=bu6b4eBS8RIxadrsxe8V9N/RqfBUEoAG+ADruwFqgTxMvis314JIGfAYlboLuk3vwYLHNBXE/wcRN9KvzZp1cDYI0oIqo+HmabV6CirX9a4gCtTyxoUPswNPmSEF1Ni0chOi9poMCwdGB5dFdUtZT3kEcvlNxxjqqhyMbG722II=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Authority-Analysis: v=2.4 cv=D+pUl9dj c=1 sm=1 tr=0 ts=65af3188
 a=pMSlDXUwMa7SJ1EIez8PdQ==:117 a=pMSlDXUwMa7SJ1EIez8PdQ==:17
 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=uZvujYp8AAAA:8
 a=S1gdvm2_QrogmFSBmPsA:9 a=CjuIK1q_8ugA:10 a=h0-zxJNUdx4A:10
 a=SLzB8X_8jTLwj6mN0q5r:22
MIME-Version: 1.0
Date: Mon, 22 Jan 2024 19:24:52 -0800
To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Cc: cygwin AT cygwin DOT com
Subject: Re: Possiblly bug of cygwin1.dll
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>
User-Agent: Roundcube Webmail/1.4.15
Message-ID: <c90e29238d7bb99ef6a8787f38585c21@kylheku.com>
X-Sender: kaz AT kylheku DOT com
X-CMAE-Envelope: MS4xfMrQ7HdKxIYE076bjNcSDatf6wAa68+gKviroRyNfE3HB0TxOG+c/ikW3qT4P/tozc7IApi6tQjFpzVKNaJh8x4VukMI9fqqiwiW1tRgvdHSvPatb+d5
 CSjcUfkgdvEMIA4PFf+NEXmhkods6bjz4dKkcfgvvQg+mvAJgpzTS0Ayca9duwTmicVWLhrUukd+csLnXmHgDFyIDiGYbdGNIWI=
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_LOW,
 SPF_HELO_NONE, 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: Kaz Kylheku via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Kaz Kylheku <kaz AT kylheku 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 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?

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.

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.

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.

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.

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