From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55810 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q50Uh-0003EI-6C for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:51:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q50Uf-0003wv-W7 for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:51:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q50Uf-0003wh-Lo for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:51:49 -0400 Date: Wed, 30 Mar 2011 20:51:46 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCHv3] report that QEMU process was killed by a signal Message-ID: <20110330185146.GD7741@redhat.com> References: <20110315115604.GY10151@redhat.com> <4D937B26.3070906@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D937B26.3070906@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org On Wed, Mar 30, 2011 at 01:49:10PM -0500, Anthony Liguori wrote: > On 03/30/2011 01:39 PM, 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. > > Or just #ifdefing this to 0 for now and then once an SDL version is > released that works correctly, adding an appropriate guard. > I prefer to move signal init after SDL init. -- Gleb.