From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta0010.nifty.com (mta-snd00014.nifty.com [106.153.226.46]) by sourceware.org (Postfix) with ESMTPS id 1E1913858D3C for ; Wed, 24 Jan 2024 11:55:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1E1913858D3C 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 1E1913858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=106.153.226.46 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 Received: from HP-Z230 by dmta0010.nifty.com with ESMTP id <20240124115515723.ZPQG.108497.HP-Z230@nifty.com> for ; Wed, 24 Jan 2024 20:55:15 +0900 Date: Wed, 24 Jan 2024 20:55:14 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: Possiblly bug of cygwin1.dll Message-Id: <20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp> In-Reply-To: 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=-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 List-Id: 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