Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()

[Blue Swirl]

On 3/17/10, Paolo Bonzini <address@hidden> 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?