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

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH 0 of 3] libxl: memory leaks
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Mon, 02 Aug 2010 13:31:10 +0100
Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
Delivery-date: Mon, 02 Aug 2010 05:32:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
The following fix a few memory leaks.

The first was discussed on list and it was decided that although it
wasn't a real leak, since the memory is allocated exactly once per
thread and is correctly cleaned up on pthread_exit(), it was still
useful for xl (a non-threaded application) to be able to be completely
valgrind clean for the purposes of auditing libxl.

The leaks fixed in xl create are just a subset since I didn't delve
into recursively freeing the types defined by libxl yet. There are
also leaks in the lexer and parser which I didn't tackle yet.

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