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: Tom Lane <>
To: Taylor R Campbell <>
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Thu, 25 Aug 2022 22:37:03 -0400

 Taylor R Campbell <> writes:
 > Can you try the attached patch series?  Do you have a quick reproducer
 > for the problem?  Ideally we could make an automatic test for this if
 > there's a cheap reproducer to trigger the race.
 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.
 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.  PLT
 resolution is pretty much the only dynamic-loader operation that
 I can foresee happening with signals enabled in the Postgres
 postmaster --- indeed, before I saw this failure I'd have sworn
 up and down that we do *nothing* interesting with signals enabled.
 That select(2) call and the adjacent sigprocmask calls are the
 entire extent of the window for trouble.
 I have no opinion about the first patch -- Postgres doesn't use
 I'll report back in a week or two.
 			regards, tom lane

Home | Main Index | Thread Index | Old Index