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

[Markus Armbruster]

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.