Re: [Xen-devel] Current LibXL Status

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] Current LibXL Status"):
> So what was the conclusion here?  It looks like we've confirmed that
> exit() is only called:
> 
> 1. In the case of a malloc() failure
> 2. in libxl-save-helper (a separate process forked by the library)
> 3. In libxl__event_disaster(), if no callback is provided
  4. In other processes forked by the library

But, yes,l basically.

> Which just leaves #1 as something to be discussed?

Is this crashing on malloc failure a problem ?

From the point of view of libxl's innards, making malloc failures
fatal means that nothing that allocates memory needs to care about
malloc failures.  That massively reduces the number of error paths to
be considered and eliminates an entire class of (largely theoretical)
bugs.

And often there is no good recovery possible (and logging the error is
hard too).

I'm not sure whether I'd want to change this policy even if someone
wanted to commit to auditing libxl and submitting the necessary
patches to cope with every malloc failure.  Having to cope with malloc
failure would be a continual burden on every proposed change or new
feature.

If in practice this is a problem it would probaby be better to run
libxl in a process which can be restarted if it dies due to malloc
failure.

Ian.

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