From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTBi4-0006k7-RU for qemu-devel@nongnu.org; Wed, 13 Aug 2008 04:28:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTBi1-0006hO-HA for qemu-devel@nongnu.org; Wed, 13 Aug 2008 04:28:00 -0400 Received: from [199.232.76.173] (port=52074 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTBi1-0006h9-8u for qemu-devel@nongnu.org; Wed, 13 Aug 2008 04:27:57 -0400 Received: from mx1.redhat.com ([66.187.233.31]:34669) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTBi0-00011g-Uy for qemu-devel@nongnu.org; Wed, 13 Aug 2008 04:27:57 -0400 Date: Wed, 13 Aug 2008 09:27:47 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] Handle terminating signals. Message-ID: <20080813082747.GB3814@redhat.com> References: <48A09722.3060106@redhat.com> <18593.24673.304649.806330@mariner.uk.xensource.com> <48A1D6A3.4050406@redhat.com> <20080812.132906.-399282484.imp@bsdimp.com> <48A1E78F.8000808@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A1E78F.8000808@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: qemu-devel@nongnu.org On Tue, Aug 12, 2008 at 09:42:07PM +0200, Gerd Hoffmann wrote: > M. Warner Losh wrote: > > In message: <48A1D6A3.4050406@redhat.com> > > Gerd Hoffmann writes: > > : > No, because the program should not attempt to catch SEGV either. > > : > > : Why not? Can you change your attitude to say "no" without giving > > : reasons please? > > > > The only portable thing one can do when catching SEGV is terminate the > > program. Otherwise, when the signal handler returns, SEGV happens > > again... > > Returning from the signal handler isn't going to work, sure. The only > thing I want do is cleaning up before exiting. > > Most apps never ever have to care about that. Sometimes there are good > reasons to attempt a cleanup even for a SEGV though. The X-Server for > example attempts to put the gfx card into a sane state then. The X server often fails to do this cleanup. This is why they're moving mode setting into the kernel so it can be *reliably* reset. Relying on a SEGV handler for cleanup is just doomed to fail 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 :|