From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6949 invoked by alias); 12 Jun 2008 16:37:11 -0000 Received: (qmail 6939 invoked by uid 22791); 12 Jun 2008 16:37:09 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jun 2008 16:36:22 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K6pmY-0004MV-Ry for gdb-patches@sourceware.org; Thu, 12 Jun 2008 20:36:18 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K6pmS-0004MI-Bt; Thu, 12 Jun 2008 20:36:08 +0400 From: Vladimir Prus To: Pedro Alves Subject: Re: SIGCHLD ignored Date: Thu, 12 Jun 2008 18:30:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org, Hamish Rodda , Daniel Jacobowitz References: <200806112121.06783.ghost@cs.msu.su> <200806112345.22321.pedro@codesourcery.com> <200806120018.05719.pedro@codesourcery.com> In-Reply-To: <200806120018.05719.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806122036.17390.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00233.txt.bz2 On Thursday 12 June 2008 03:18:05 Pedro Alves wrote: > [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. This patch works fine for me, and (with my limited understanding of the code), makes sense. Can we get it in? - Volodya