[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    Re: library/5762: rthreads segvs up after fork()
From:       Philip Guenther <guenther () sendmail ! com>
Date:       2008-03-28 17:34:36
Message-ID: alpine.BSO.1.00.0803281053200.23134 () vanye ! mho ! net
[Download RAW message or body]

On Fri, 28 Mar 2008, Kurt Miller wrote:
> On Friday 28 March 2008 2:24:59 am Philip Guenther wrote:
>> I'll start this by mentioning that the patch in the PR should be
>> considered superseded by the fork() parts of the patch I posted to the
>> tech list on March 23rd.
>
> Ahh I didn't review that one. In general that's going to need to be
> chopped up in to logical parts so it can be properly reviewed before
> committing.

Certainly.  I spewed them all together to increase the chance of getting 
feedback from the horde.


> I can help review the userland side of things but others will need to 
> help with the kernel changes. We might as well finish the 
> fork/vfork/atfork review now.
...
>> I used the program at the bottom of this message to investigate how
>> Solaris 10 and Linux 2.6.9 with glibc 2.3.4 (the newest I have trivial
>> access to) behave.
...
> Thanks for investigating it. Based on the information you've provided 
> above and my own investigation I've concluded that vfork() should skip 
> the atfork handlers. Since our system() and popen() implementations use 
> vfork() they will skip them too. I will move a diff forward that adjusts 
> libpthread and the vfork(), system() and popen() man pages.

Yeah, having libpthread and librthread match will be a Good Thing.


...
>> So yeah, the kernel side of fork would need to provide help to close that
>> completely.
>
> My example of SEGV in an atfork prepare handler was not ideal. However, 
> It was unclear from your responses above if you are still advocating 
> blocking signals for the atfork handlers.

I was just kind of trying to talk out the issues there.  Both options have 
sucky aspects, it's just a matter of which we want to accept.


> I have checked FreeBSD's and Linux's threaded fork code and I see that 
> neither of them block signals while the atfork handler are executing and 
> I'm still of the opinion that signal blocking should be minimized to 
> reduce the window where they are blocked.

Sounds like the community at large has settled on biting the "don't call 
fork() from signal handlers unless you're disciplined" bullet to avoid the 
issues from blocking signals.  Following the consensus makes sense then.


...
>> My opinion is that the library should make sure that things work correctly
>> if a program linked with rthreads calls fork() while it has only a single
>> thread, but that if you have another thread running all bets are off and
>> the app better be following the XPG "async-signal-safe functions only"
>> rule.
>
> I agree. However to the extent that things can safely be reset we should
> endever to do so. In any case, it seems like your tech@ version covers more
> cases. I'd like to see a new diff that incorporates the feeback so far so this
> can move forward.

Okay.  My parents are in town this weekend and next week, so it may be a 
bit.


Philip Guenther

[prev in list] [next in list] [prev in thread] [next in thread]