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: References: <20240119224436 DOT 876a055f356f7c6796bc725b AT nifty DOT ne DOT jp> <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=-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano 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" 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 > > 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 -- 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