SIGCHLD ignored

A fellow KDevelop hacker has reported that when running
kdevelop itself
under CVS HEAD of gdb, kdevelop hangs. What happens if that
kdevelop spawns
subprocess, and then does not notice it has exited, because
it never
receives SIGCHLD. I attach a much reduced project that
requires only Qt4,
and probably an even more reduced project is possible.

If I apply the attached patch to GDB, things work fine --
but I suspect
this 'fix' will break something else. 

Pedro, I think this SIGCHLD magic is your doing -- do you
have any ideas
how to fix it? 

Thanks,
Volodya

On Wed, Jun 11, 2008 at 09:21:05PM +0400, Vladimir Prus
wrote:
> 
> A fellow KDevelop hacker has reported that when running
kdevelop itself
> under CVS HEAD of gdb, kdevelop hangs. What happens if
that kdevelop spawns
> subprocess, and then does not notice it has exited,
because it never
> receives SIGCHLD. I attach a much reduced project that
requires only Qt4,
> and probably an even more reduced project is possible.
> 
> If I apply the attached patch to GDB, things work fine
-- but I suspect
> this 'fix' will break something else. 
> 
> Pedro, I think this SIGCHLD magic is your doing -- do
you have any ideas
> how to fix it? 

linux_nat_create_inferior is already unblocking signals
before
creating.  Does normal_mask contain SIGCHLD?

The approach taken (search for "signal" in
fork-child.c, first
comment) may not be compatible with async...

-- 
Daniel Jacobowitz
CodeSourcery

On Wed, 2008-06-11 at 22:08 +0400, Vladimir Prus wrote:

> I actually would appreciate some comments about what we
do with SIGCHLD
> in linux-nat.c -- the code is fairly complex to
understand this by
> reading.

Ha ha, yes.  Legacy of old linux threads model, I think.

If we change anything in that area, we should probably test
to make sure gdb still works on old linux thread model.

Unles we want to decide that we no longer support that --
but I believe there are still platforms that have not
converted over to NPTL threads (or have done so only
recently).

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.

-- 
Pedro Alves

[Discussion moved to gdb-patches]
http://sources.redhat.com/ml/gdb-patches/2008-06/m
sg00228.html

-- 
Pedro Alves