Re: [Xen-devel] Current LibXL Status

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-02-18 at 17:19 +0000, Ian Jackson wrote:
> 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 ?

It is for non-C language bindings which might be using garbage collection,
since they might be OOM from a malloc perspective but actually have loads
of spare memory waiting to be collected (which they might plausibly be
doing quite lazily).

I just reminded people of my proposal to provide a callback to allow the
app/bindings to run their gc here in my reply to George before I saw your
reply.

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

I agree that we don't want to change this policy, but I think an OOM hook
is sufficient to solve the actual problem.


> 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