From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQfdu-000322-U4 for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:49:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQfdt-000316-5E for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:49:17 -0400 Received: from [199.232.76.173] (port=39745 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQfdr-00030v-PC for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:49:15 -0400 Received: from mx1.redhat.com ([66.187.233.31]:54520) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQfdr-0007Cx-BN for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:49:15 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m769mtP6028967 for ; Wed, 6 Aug 2008 05:48:55 -0400 Date: Wed, 6 Aug 2008 10:48:53 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] catch signals Message-ID: <20080806094853.GF9055@redhat.com> References: <48987B43.4090207@redhat.com> <20080805163519.GV6570@redhat.com> <48996CE7.5010205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48996CE7.5010205@redhat.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On Wed, Aug 06, 2008 at 11:20:39AM +0200, Gerd Hoffmann wrote: > Daniel P. Berrange wrote: > > On Tue, Aug 05, 2008 at 06:09:39PM +0200, Gerd Hoffmann wrote: > >> > >> +#ifndef _WIN32 > >> +static void termsig_handler(int signal) > >> +{ > >> + switch (signal) { > >> + case SIGSEGV: > >> + case SIGBUS: > >> + /* returning from signal handler most likely isn't going to work */ > >> + fprintf(stderr, "qemu: got signal %d (%s), taking emergency exit\n", > >> + signal, strsignal(signal)); > >> + exit(1); > > > > Neither of these functions are on the POSIX async-signal-safe list, > > so their use from signal handlers is not a good idea. > > We are in dead water already and also don't plan to ever return from the > signal handler. Is it really a problem then? Yes, because if you further corrupt state in the signal handler it makes debugging what went wrong even harder than it already is. In SEGV/BUS case you really want to be able to get a decent core dump to analyse, so the utmost care should be taken to avoid further messing up state. The STDIO libs are not re-entrant safe so if the original code was in a STDIO function, and a SEGV comes in on another thread, the signal handler will likely deadlock in a mutex. 'exit' will call into STDIO to flush buffers, so will suffer the same problem. > I want to be able to do cleanups (well, at least attempt) even in case > of a segfault. If exit() + atexit handlers isn't going to fill the bill > we'll have to create some signal-save emergency cleanup handlers. You could use 'sigaltstack' to setup an alternate pre-allocated stack and carefully code the handler so it only uses pre-allocated memory, or mem from the alt-stack & signal-safe functions. If you need something really complex, you could 'fork' a cleanup program and communicate any info to it using a pipe. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|