This is the mail archive of the
mailing list for the GDB project.
Re: SIGCHLD ignored
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Hamish Rodda <rodda at kde dot org>, Daniel Jacobowitz <dan at codesourcery dot com>
- Date: Thu, 12 Jun 2008 20:36:17 +0400
- Subject: Re: SIGCHLD ignored
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Thursday 12 June 2008 03:18:05 Pedro Alves wrote:
> [moved to gdb-patches@]
> Original report here:
> SIGCHLD ignored
> 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.
This patch works fine for me, and (with my limited understanding of the code),
makes sense. Can we get it in?