Re: [Qemu-devel] [PATCH 3/3] qtest: kill QEMU process on g_assert() failure

[Stefan Hajnoczi]

On Tue, Feb 18, 2014 at 11:43:10AM +0100, Markus Armbruster wrote:
> Paolo Bonzini <address@hidden> writes:
> 
> > Il 18/02/2014 11:05, Markus Armbruster ha scritto:
> >>> > Yes, SIGABRT is synchronous for all purposes.  So the only danger is
> >>> > that g_string_free() or g_free() could fail while we're in
> >>> > g_assert(false).  But they don't, which makes sense because they are
> >>> > totally unrelated to g_assert() and therefore can handle re-entrancy.
> >> The (theoretical!) problem is when it aborts in the bowels of g_*free(),
> >> and your SIGABRT handler reenters g_*free().
> >>
> >>> > In practice there is no issue and I've tested assertion failure with
> >>> > glib 1.2.10.
> >> Worst that can happen is we crash on the way from abort() to process
> >> termination.  Tolerable.
> >
> > What about recursive locking of a non-recursive mutex?
> 
> You're right, deadlock is possible.  Strengthens the argument for:
> 
> >> Still, avoiding unnecessary cleanup on that path seems prudent to me.
> >> If you agree, factor out the kill()/waitpid(), and call only that from
> >> the signal handler.

Okay, I'm convinced.