This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 0 of 3] libxl: memory leaks

On Tue, 2010-08-03 at 08:59 +0100, Vincent Hanquez wrote:
> On 02/08/10 15:05, Gianni Tedesco (3P) wrote:
> > It's no big secret or mystery - I only mentioned it because I had
> > planned to start work on it quite soon :)
> >
> > Basically it is to implement properly the current pointer tracking code
> > in libxl such that allocations via libxl_(sprintf|malloc) and so on are
> > automatically free'd when returning out of the library to a caller.
> > Objects returned to callers will still be expected to be free()'d...
> What about, what's wrong with the original design ?
> the original design being you stuff everything in the context memtrack 
> and expect all the objects allocated by libxl (internal AND returned to 
> the caller) to be free by a ctx_free. This provides a strong proven 
> guarantee that *everything* has been free.

I wasn't aware that was the original design. It's certainly not the case
right now.

AFAICS that scheme would only guarantee everything has been freed if the
caller calls ctx_free() at appropriate points. If libxl were used in a
daemon, for example, it would not be simple to come up with a scheme
that guarantees memory bounds that are independent from uptime.

Also, a simpler way to free everything is exit() :)

Xen-devel mailing list