NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/56979: fork(2) fails to be signal safe

The following reply was made to PR lib/56979; it has been noted by GNATS.

From: Taylor R Campbell <>
To: Tom Lane <>
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Fri, 26 Aug 2022 08:38:10 +0000

 > Date: Thu, 25 Aug 2022 22:37:03 -0400
 > From: Tom Lane <>
 > I've built the system with that patch added, and will start using it
 > tomorrow.  I do not have a reliable reproducer, and on reflection it's
 > hard to see how to make one -- unless you know of an operation that
 > would hold the rtld lock for a decently long period of time.  However,
 > I'm finding that my macppc Postgres buildfarm instance [1] is hitting
 > this in perhaps one out of five or ten runs, so if it can survive for
 > a week or two then I'll feel pretty confident that this patch fixes
 > it for me.
 Cool, thanks!
 > FWIW, the second patch certainly looks like it will alleviate the
 > symptom I'm seeing.  I suppose it would not fix cases where the
 > signal interrupts an operation holding the rtld lock exclusively;
 > but I do not think that will be a problem for my use-case.
 The rtld exclusive lock blocks signals (except for SIGTRAP, which
 might be a bug...).
 > I have no opinion about the first patch -- Postgres doesn't use
 > pthread_atfork.
 Perhaps not, but if you did, and if a signal interrupted
 pthread_atfork triggering a signal handler that calls fork, then
 fork's attempts to invoke the atfork handlers might see the data
 structures in the middle of an update.

Home | Main Index | Thread Index | Old Index