[Libvir] RFC: safer memory allocation APIs with compile time checking

Daniel Veillard veillard at redhat.com
Tue Apr 29 06:39:25 UTC 2008


On Mon, Apr 28, 2008 at 06:45:54PM +0000, David Lutterkort wrote:
> 
> On Mon, 2008-04-28 at 13:38 +0100, Richard W.M. Jones wrote:
> > On Mon, Apr 28, 2008 at 03:39:41AM -0400, Daniel Veillard wrote:
> > >   Calling abort() in a library is a major NO-NO and one of the reasons
> > > I avoided glib in most of the code I developped. You just can't exit()/abort()
> > > from a library.
> > 
> > That depends ... If you can override the abort() function with an
> > error handler, then I'd say it is OK.
> 
> I used to not think very highly of calling abort() by default, but
> reading Havoc's blog post about that a while ago[1] is making me doubt
> conventional wisdom. He cites libxml2 as one example where OOM leads to
> crashes - I take that not as an indication that there is something wrong
> with libxml2, but with the approach of checking and correctly handling
> all allocation failures.

  It's a matter of testing, Havoc looked at it some years ago, but now
the Huawei people (embedded/telecom) are chasing the behaviour on OOM
systematically. Of course the more dynamic and complex the data structures
are the harder it is, and XML tree processing is on the hard side 
unfortunately.

> Allocation failure happens very rarely, and testing it properly is near
> impossible; allocation failures amount to an additional input stream
> that is read deep down in the call hierarchy and can generally not be
> checked by the caller like other arguments.

  you can, you do fault injection, testing systematically each allocation
done during a test run, computationally expensive for sure, but doable,
it's being done...

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list