Paolo Bonzini <[email protected]> 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.
