From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFhax-0002Ns-PB for qemu-devel@nongnu.org; Tue, 18 Feb 2014 05:08:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFhap-0007iN-7Z for qemu-devel@nongnu.org; Tue, 18 Feb 2014 05:08:07 -0500 Received: from mail-ea0-x233.google.com ([2a00:1450:4013:c01::233]:53240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFhao-0007iG-LA for qemu-devel@nongnu.org; Tue, 18 Feb 2014 05:07:59 -0500 Received: by mail-ea0-f179.google.com with SMTP id q10so7110839ead.24 for ; Tue, 18 Feb 2014 02:07:57 -0800 (PST) Sender: Paolo Bonzini Message-ID: <530330F9.5070608@redhat.com> Date: Tue, 18 Feb 2014 11:07:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1392651898-16749-1-git-send-email-stefanha@redhat.com> <1392651898-16749-4-git-send-email-stefanha@redhat.com> <530235F0.2040406@redhat.com> <87a9dpsmi4.fsf@blackfin.pond.sub.org> <20140218090504.GB32585@stefanha-thinkpad.redhat.com> In-Reply-To: <20140218090504.GB32585@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] qtest: kill QEMU process on g_assert() failure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Markus Armbruster Cc: Peter Maydell , Stefan Hajnoczi , qemu-devel@nongnu.org, Anthony Liguori , Andreas Faerber Il 18/02/2014 10:05, Stefan Hajnoczi ha scritto: >> > 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. If malloc aborts due to a double free or other similar problem, you may risk reentering it. Paolo