[moved to gdb-patches@]

Original report here:
 SIGCHLD ignored
 http://sourceware.org/ml/gdb/2008-06/msg00099.html

A Wednesday 11 June 2008 23:45:22, Pedro Alves wrote:
> A Wednesday 11 June 2008 18:21:05, Vladimir Prus wrote:
> > Pedro, I think this SIGCHLD magic is your doing -- do you have any ideas
> > how to fix it?
>
> Dang, I totally missed this could be a problem.
>
> Right, so, normal_mask has SIGCHLD blocked in _initialize_linux_nat,
> and since forking a child inherits the signal mask, the child gets
> SIGCHLD blocked by default.  This would have gone unnoticed
> if Qt unblocked SIGCHLD in it's setup (one may argue it should).
>
> It's not safe to just remove that SIGCHLD blocking, we're not
> taking care of blocking it in places we used to in sync mode
> (we used to block it the first time we hit linux_nat_wait, which
> is reached after forking an inferior).
>
> For async mode, we also need to do something about SIGCHLD
> blocking.  We have:
>
> linux_nat_create_inferior
>   -> linux_nat_async_mask
>      -> linux_nat_async
>         -> linux_nat_async_events
>            -> block SIGCHLD.
>
>   -> linux_ops->to_create_inferior (forks a child)
>
> Attached is a patch to fix this.
>
> Basically, I turned linux_nat_async_events_enabled into a
> 3-state instead of a bool, with the new state being
> "SIGCHLD unblocked with action set to whatever we get
> on startup".  Most of the SIGCHLD state management stays with
> the same logic, except that linux_nat_create_inferior gets a
> switch to the new state before forking a child, and
> linux_nat_wait, gets an unconditional switch to the blocked
> state.  The rest of the patch is mostly updating to the
> new interface.
>
> Tested on x86-64-unknown-linux-gnu sync and async modes
> without regressions.

Same code patch, but updated with a new testcase.  I imagine
we're going to touch these issues again with full
multi-process support.

-- 
Pedro Alves