From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9zTY-00048I-QG for qemu-devel@nongnu.org; Fri, 29 May 2009 06:38:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9zTT-00046v-5V for qemu-devel@nongnu.org; Fri, 29 May 2009 06:38:12 -0400 Received: from [199.232.76.173] (port=45016 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9zTS-00046m-Ua for qemu-devel@nongnu.org; Fri, 29 May 2009 06:38:06 -0400 Received: from mx2.redhat.com ([66.187.237.31]:37685) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9zTR-0004XM-FP for qemu-devel@nongnu.org; Fri, 29 May 2009 06:38:05 -0400 Message-ID: <4A1FBA45.80902@redhat.com> Date: Fri, 29 May 2009 12:34:45 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently References: <200905290758.11551.jcd@tribudubois.net> <4A1F9FFE.3030100@redhat.com> <4A1FA573.4010602@codemonkey.ws> <4A1FB37E.5040602@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Paul Brook , qemu-devel@nongnu.org, Jean-Christophe Dubois malc schrieb: > On Fri, 29 May 2009, Kevin Wolf wrote: > >> malc schrieb: >>>> Putting the abort() in there is going to introduce a ton of subtle bugs, >>>> I vote for changing qemu_malloc() to have a sane behavior. >>> And those will be caught, given one a chance to analyze things, unlike >>> head in the sand approach of hoping things would just work. >>> >>> After doing some research, after the aforementioned lengthy discussion, >>> the only free OS that straight-forwardly described what it does was >>> OpenBSD: >>> >>> http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html >>> >>> P.S. So far the abort that went into qemu_malloc caught one usage of zero >>> allocation (once again coming from qcow2). >> Zero allocation isn't a bug per se. Checking for NULL or dereferencing >> is. Any value that can be freed, be it NULL or anything else, was >> perfectly fine here without the abort() patch. So it actually was one of >> the subtle bugs Anthony mentioned which are introduced by the abort(). > > And once again, the code would have aborted on AIX with our without abort > patch. The reason for abort is to identify and reason about all the call > sites that do that. Why would it have aborted? If AIX aborts on malloc(0), its malloc is seriously broken. But as I have understood from previous discussion, AIX just returns NULL. Would have been okay for this code. Kevin