From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LV3Fl-00043W-8G for qemu-devel@nongnu.org; Thu, 05 Feb 2009 07:22:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LV3Fi-000432-Ri for qemu-devel@nongnu.org; Thu, 05 Feb 2009 07:22:44 -0500 Received: from [199.232.76.173] (port=60061 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LV3Fi-00042t-OU for qemu-devel@nongnu.org; Thu, 05 Feb 2009 07:22:42 -0500 Received: from mx2.redhat.com ([66.187.237.31]:54779) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LV3Fi-0006Q9-Bn for qemu-devel@nongnu.org; Thu, 05 Feb 2009 07:22:42 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n15CMfBw008728 for ; Thu, 5 Feb 2009 07:22:41 -0500 Message-ID: <498ADA0F.80006@redhat.com> Date: Thu, 05 Feb 2009 14:22:39 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/6] Terminate emulation on memory allocation failure References: <1233832126-9046-1-git-send-email-avi@redhat.com> <1233832126-9046-2-git-send-email-avi@redhat.com> <20090205120115.GJ2759@redhat.com> In-Reply-To: <20090205120115.GJ2759@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Thu, Feb 05, 2009 at 01:08:41PM +0200, Avi Kivity wrote: > >> Memory allocation failures are a very rare condition on virtual-memory >> hosts. They are also very difficult to handle correctly (especially in a >> hardware emulation context). Because of this, it is better to gracefully >> terminate emulation rather than executing untested or even unwritten recovery >> code paths. >> >> This patch changes the qemu memory allocation routines to terminate emulation >> if an allocation failure is encountered. >> >> Signed-off-by: Avi Kivity >> --- >> qemu-malloc.c | 16 ++++++++++------ >> 1 files changed, 10 insertions(+), 6 deletions(-) >> >> diff --git a/qemu-malloc.c b/qemu-malloc.c >> index dc74efe..1d00f26 100644 >> --- a/qemu-malloc.c >> +++ b/qemu-malloc.c >> @@ -22,6 +22,14 @@ >> * THE SOFTWARE. >> */ >> #include "qemu-common.h" >> +#include >> + >> +static void *oom_check(void *ptr) >> +{ >> + if (ptr == NULL) >> + exit(13); >> + return ptr; >> +} >> > > Will all our atexit handlers cope with OOM too? In particular > we don't want them calling qemu_malloc again, or this becomes > re-entrant. If we want to go down this route, then abort() is > probably safer. abort() is a little messy in leaving a core file (which would likely fail anyway if we're out of memory). Maybe _exit() is better here. Even exit() will work; if we are unable to allocate in the exit handler, worst case we overflow the stack and crash. In any case, I didn't see any calls to qemu_malloc() in existing atexit handlers. -- error compiling committee.c: too many arguments to function