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@cygwin.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." -- 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
