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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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

> 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