Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib

[Stefan Hajnoczi]

On Wed, Jan 26, 2011 at 3:53 PM, Anthony Liguori
<address@hidden> wrote:
> On 01/25/2011 10:47 PM, Daniel Veillard wrote:
>>
>> On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
>>
>>>
>>> Both the recent I/O loop and threadlet series have me concerned that
>>> we're
>>> digging ourselves deeper into the NIH hole.  I think it's time we look at
>>> something radical to let us borrow more code from existing projects
>>> instead of
>>> reinventing everything through trial and error.
>>>
>>> This series introduces a hard dependency on glib.  The initial use is
>>> portable
>>> threads but I see this as just the beginning.  Glib/Gobject offer many
>>> nice
>>> things including:
>>>
>>>  - portable threads
>>>  - rich data structure support
>>>  - INI parser
>>>  - JSON parser
>>>  - generic type system
>>>  - object oriented infrastructure
>>>  - IO library
>>>  - module system
>>>  - introspection to enable support for dynamic language bindings
>>>
>>> I see this series as the first step, followed by converting the I/O loop
>>> to
>>> a GMainLoop instance.  Once we're there, we can start making deeper use
>>> of
>>> GObjects including converting QDev to a GObject hierarchy.
>>>
>>
>>   Hum, one of the reason I tried to avoid glib dependancies on my own
>> libraries code is the behaviour on memory allocation error, unless that
>> changed (unlikely) or my recollection is wrong (more likely) glib does
>> a direct exit() on memory allocation errors. This might be fine for QEmu
>> as a standalone program but may turn a disaster if standalone libraries
>> are made out of it and expected for reuse say by libvirt(d).
>>
>
> We have independently done the same thing in QEMU and as such would face the
> same "problem" either way.
>
> Quite a debate could be had on the merits of this.  For QEMU, we made this
> decision for practical purposes.  We did not handle malloc failures
> consistently so adopting a consistent behavior eliminated the possibility of
> NULL pointer dereferences which are exploitable.

Both g_malloc() and g_try_malloc() are available where g_try_malloc()
returns NULL on failure.  g_malloc() matches qemu_malloc() exit
behavior today but in the future it would be possible to use
g_try_malloc() for proper out-of-memory handling.

But I think you're pointing out that glib uses g_malloc() internally.
That is a design flaw and basically makes g_try_malloc() useless.

Stefan