From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NrzGe-0006Tl-0b
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 15:51:00 -0400
Received: from [199.232.76.173] (port=42945 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NrzGd-0006So-FN
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 15:50:59 -0400
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <blauwirbel@gmail.com>) id 1NrzGc-0004X2-Lh
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 15:50:59 -0400
Received: from mail-pv0-f173.google.com ([74.125.83.173]:50497)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1NrzGc-0004Wy-CC
	for qemu-devel@nongnu.org; Wed, 17 Mar 2010 15:50:58 -0400
Received: by pvf33 with SMTP id 33so738507pvf.4
	for <qemu-devel@nongnu.org>; Wed, 17 Mar 2010 12:50:57 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <4BA09C72.9060201@redhat.com>
References: <f43fc5581003130656j408f64bfp7fe4bf486c625624@mail.gmail.com>
	<m3sk82nj16.fsf@blackfin.pond.sub.org>
	<f43fc5581003151023g354dc74cr989f3373f5f1de9a@mail.gmail.com>
	<m3vdcx8ma9.fsf@blackfin.pond.sub.org> <hnnf7e$8f9$1@dough.gmane.org>
	<m3ljds3auv.fsf@blackfin.pond.sub.org>
	<20100316175523.GD19160@shareable.org> <4BA09C72.9060201@redhat.com>
Date: Wed, 17 Mar 2010 21:50:57 +0200
Message-ID: <f43fc5581003171250h7d30e0adt4c6f52ee52ce24ce@mail.gmail.com>
Subject: Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or
	cpu_abort()
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

On 3/17/10, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 03/16/2010 06:55 PM, Jamie Lokier wrote:
>
> > A guest program is also allowed to trap SIGABRT with a signal handler,
> > and that does have some uses.  E.g. cleaning up temporary files and
> > shmem segments following a crash when calling 3rd party code.
> >
> > Whatever the guest does with SIGABRT, it should not result in_QEMU_
> > crashing - whether due to abort() returning, or QEMU's control flow
> > jumping to the guest's signal handler from an unexpected location.
> >
>
>  That's very hard to ensure however if QEMU was already in unstable state,
> as witnessed by its call to abort().  Things can only go downhill.
>
>  Maybe there should be a qemu_abort wrapper (and a QEMU_ASSERT companion)
> that does simply abort/assert under system emulation, but under user-mode
> emulation does
>
>   signal (SIGABRT, SIG_DFL);
>   abort ();

Fine, we cover this obscure corner case. But what if in addition to
this, the user process forked and the other process ptraced the QEMU
process, and when QEMU attempts to install the default signal handler,
the call is instead diverted to somewhere else with ptrace?