On Mon, Feb 17, 2014 at 06:00:03PM +0100, Markus Armbruster wrote: > Paolo Bonzini <[email protected]> writes: > > > Il 17/02/2014 16:44, Stefan Hajnoczi ha scritto: > >> } > >> > >> +static void sigabrt_handler(int signo) > >> +{ > >> + qtest_end(); > >> +} > >> + > > > > void qtest_quit(QTestState *s) > > { > > int status; > > > > if (s->qemu_pid != -1) { > > kill(s->qemu_pid, SIGTERM); > > waitpid(s->qemu_pid, &status, 0); > > } > > > > close(s->fd); > > close(s->qmp_fd); > > g_string_free(s->rx, true); > > g_free(s); > > } > > > > Not async-signal safe. You need to ignore the g_string_free and > > g_free (perhaps even the closes) if calling from the sigabrt_handler. > > kill(), waitpid() and close() are all async-signal-safe. > > SIGABRT is normally synchronous enough: it's sent by abort(). But of > course, nothing stops the user from kill -ABRT. Or GLib from calling > abort() in some place where an attempt to reenter it crashes & burns. > Not sure I'd care, but I'm pretty sure I don't care for freeing stuff on > exit :)
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. In practice there is no issue and I've tested assertion failure with glib 1.2.10. Stefan
