Re: [Xen-devel] [PATCH 09/20] libxl: Crash (more sensibly) on malloc failure

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-03-20 at 16:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 09/20] libxl: Crash (more 
> sensibly) on malloc failure"):
> > I guess the log infrastructure does (or could do) memory allocation and
> > so can't be used here in the normal way.
> 
> Yes.
> 
> > Perhaps libxl could format a (short) message into a static emergency
> > buffer and use a (new, optional) emergency variant of the logger
> > callback which does not accept a format string, which should maximise
> > the chances of writing to the log? Even if we could just get the message
> > "Out of memory, aborting" into the logs that would be useful.
> 
> In fact libxl__logv already has this special case built-in.
> 
> > My concern is that many users of libxl will not necessarily be capturing
> > stderr and so the appearance will be of random unexplained exiting.
> 
> Yes.  Good point.  I will fix this, and have it call libxl__log as
> well as printing to stderr.

Great, thanks.

> > >  - libxl__ptr_add now returns void as it crashes on failure.
> > >  - libxl__zalloc, _calloc, _strdup, _strndup, crash on failure using
> > >    libxl__alloc_failed.  So all the code that uses these can no longer
> > >    dereference null on malloc failure.
> > 
> > I took a look for a gcc __attribute__ which means "cannot return NULL"
> > but sadly there doesn't seem to be one, this would have allowed gcc to
> > warn us about (now) pointless error handling.
> 
> Do we really need a warning about this ?  It's harmless.

More as a guide to help us to easily find and nuke all the unnecessary
error handling, rather than because it's something to worry about.

> > I don't know if gcc is
> > smart enough to catch this if we make each of these a macro which did
> >     if (!res) abort()
> > (or something similar) after calling the inner-function which does the
> > work, I don't think it's worth the effort anyway.
> 
> Quite.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel