WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Gianni Tedesco (3P)" <gianni.tedesco@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 3] libxl: memory leaks
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Tue, 3 Aug 2010 08:59:15 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Aug 2010 01:00:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1280757928.18490.72.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1280752270@xxxxxxxxxxxxxxxxxxxxx> <1280754703.18490.65.camel@xxxxxxxxxxxxxxxxxxxxxx> <4C56C60D.5060702@xxxxxxxxxxxxx> <1280757928.18490.72.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5
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.

--
Vincent

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel