From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQfCH-0006Bq-B7 for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:20:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQfCF-0006AC-1S for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:20:44 -0400 Received: from [199.232.76.173] (port=36260 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQfCE-00069v-Oq for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:20:42 -0400 Received: from mx1.redhat.com ([66.187.233.31]:36395) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQfCE-0001JP-FD for qemu-devel@nongnu.org; Wed, 06 Aug 2008 05:20:42 -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 m769KgYB019701 for ; Wed, 6 Aug 2008 05:20:42 -0400 Message-ID: <48996CE7.5010205@redhat.com> Date: Wed, 06 Aug 2008 11:20:39 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] catch signals References: <48987B43.4090207@redhat.com> <20080805163519.GV6570@redhat.com> In-Reply-To: <20080805163519.GV6570@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org 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? 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. >> + vm_start(); /* In case we're paused */ > > I think rather than trying todo anything in the signal handler, > it is safest to just set a flag and have its state checked > and acted upon in the main loop. Isn't going to fly for SIGSEGV and SIGBUS. Agree for the other signals. I'll go check whenever we can handle stopped cpus some other way (guess I just need an additional check in the main_loop() function). cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/