[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently

From: malc
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 14:40:16 +0400 (MSD)

On Fri, 29 May 2009, Kevin Wolf wrote:

> 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.

Because of oom_check in qemu_malloc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]