DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 53A6XcD83122463
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B001038618BF
Date: Wed, 9 Apr 2025 23:32:38 -0700 (PDT)
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: pthread_atfork vs dlopen/dlclose
In-Reply-To: <b150c1e4-b3cd-4f90-8548-0c5f287948d4@jdrake.com>
Message-ID: <94af5480-167a-fcc6-5f4c-89afa5ce8637@jdrake.com>
References: <07665688-8199-2e80-cdfe-abeaa6f56ba7 AT jdrake DOT com>
 <2021152719 DOT 99592 DOT 1744265074916 AT mail DOT yahoo DOT com>
 <b150c1e4-b3cd-4f90-8548-0c5f287948d4 AT jdrake DOT com>
MIME-Version: 1.0
Precedence: list
From: Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jeremy Drake <cygwin AT jdrake DOT com>
Content-Type: text/plain; charset="utf-8"
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>
Content-Transfer-Encoding: 8bit

On Wed, 9 Apr 2025, Jeremy Drake via Cygwin wrote:

> On Thu, 10 Apr 2025, Kevin Schnitzius via Cygwin wrote:
>
> > On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin <cygwin AT cygwin DOT com> wrote:
> >
> > > The recent issue with pthread_atfork handlers reminded me of a scenario
> > > that I know glibc handles, but it seems that Cygwin does not.  Test case:
> >
> > <... code that loads a shared lib, registers some functions in shared lib with pthread_atfork(), unloads the shared lib, and crashes on fork...>
> >
> > Calling functions in an unloaded library should result in undefined behavior.
> >
> > However, further investigation reveals that the Linux pthread_atfork() registered functions are not being called and POSIX does not proved a mechanism for un-registering these functions.   Note: pthread_atfork() is not bumping the ref count on the shared lib--those functions are definitely unavailable after the dlclose()
> >
> > In the Cygwin version, calling the functions in the unloaded library when the fork happens causes the crash.
> >
> > This seems to be a bug with fork(), if it is a bug at all.
>
> I did a quick search, and found a write-up of *my* bug report :D
>
> https://developers.redhat.com/articles/2022/12/14/how-we-addressed-unforeseen-use-case-pthreadatfork
>
> "Now, dlclose()'ing a module means that any fork handlers registered by it
> should not be executed after the dlclose and should therefore implicitly
> be deregistered."

It seems glibc takes care of this implicit deregistration in
__cxa_finalize, after calling __cxa_atexit functions, it unregisters any
at_quick_exit or pthread_atfork callbacks from the DSO being unloaded.

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/cxa_finalize.c;h=2bb35602edc6bf842e5d2c93ad03454d7b57ee65;hb=HEAD

It doesn't look like newlib deals with either at_quick_exit or
pthread_atfork handlers in its __cxa_finalize implementation.

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