From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34934 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5AXv-0005LY-SP for qemu-devel@nongnu.org; Thu, 31 Mar 2011 01:35:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5AXu-00017I-Re for qemu-devel@nongnu.org; Thu, 31 Mar 2011 01:35:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5AXu-000179-Fv for qemu-devel@nongnu.org; Thu, 31 Mar 2011 01:35:50 -0400 Date: Thu, 31 Mar 2011 07:35:39 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCHv3] report that QEMU process was killed by a signal Message-ID: <20110331053539.GA24181@redhat.com> References: <20110315115604.GY10151@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Peter Maydell , qemu-devel@nongnu.org On Thu, Mar 31, 2011 at 01:35:31AM +0400, malc wrote: > On Wed, 30 Mar 2011, Peter Maydell wrote: > > > On 15 March 2011 11:56, Gleb Natapov wrote: > > > Currently when rogue script kills QEMU process (using TERM/INT/HUP > > > signal) it looks indistinguishable from system shutdown. Lets report > > > that QEMU was killed and leave some clues about the killer identity. > > > > Unfortunately this patch causes qemu to segfault when killed > > via ^C (at least on my Ubuntu maverick system). This is because > > it registers a signal handler with sigaction, but then later > > the SDL library is initialised and it reinstalls our handler > > with plain old signal: > > > > ohandler = signal(SIGINT, SDL_HandleSIG); > > if ( ohandler != SIG_DFL ) > > signal(SIGINT, ohandler); > > > > This is clearly buggy but on the other hand SDL is pretty widely > > deployed and it's the default QEMU video output method, so I think > > we need to work around it :-( > > > > The most straightforward fix is to get the signal number from > > argument one and not to bother printing the PID that killed us. > > > > Maybe using SDL_INIT_NOPARACHUTE is worth doing? > We do it already, but SDL mangles signal handlers anyway. The funny thing is that parachute code actually correctly use sigaction when available. -- Gleb.