From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14559 invoked by alias); 11 Jun 2008 18:09:14 -0000 Received: (qmail 14551 invoked by uid 22791); 11 Jun 2008 18:09:13 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jun 2008 18:08:53 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K6Ukd-0000TZ-E4 for gdb@sources.redhat.com; Wed, 11 Jun 2008 18:08:51 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jun 2008 18:08:51 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jun 2008 18:08:51 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: SIGCHLD ignored Date: Wed, 11 Jun 2008 18:09:00 -0000 Message-ID: References: <200806112121.06783.ghost@cs.msu.su> <20080611173626.GA25045@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00102.txt.bz2 Daniel Jacobowitz wrote: > 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? It does not, at least when the normal_mask is initially obtained. linux_nat_create_inferior does restore the mask. Still, my test case does not work. > The approach taken (search for "signal" in fork-child.c, first > comment) may not be compatible with async... 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. - Volodya