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

[Kevin Wolf <kwolf@redhat.com>]

malc schrieb:
> 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.

Ok, you're right there, of course. This is a bug in qemu_malloc and the
reason why we even discussed changing the check in qemu_malloc.

But this is not qcow2's fault, so the fix should really be local to
qemu_malloc like it already was for qemu_realloc.

Kevin