2009/12/11 Daniel Veillard <veillard@redhat.com>:
On Fri, Dec 11, 2009 at 02:13:24AM +0100, Matthias Bolte wrote:
--- daemon/remote.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c index 3117615..7a43046 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -4118,12 +4118,15 @@ remoteDispatchStorageVolCreateXmlFrom (struct qemud_server *server ATTRIBUTE_UNU
clonevol = get_nonnull_storage_vol (conn, args->clonevol); if (clonevol == NULL) { + virStoragePoolFree(pool); remoteDispatchConnError(rerr, conn); return -1; }
newvol = virStorageVolCreateXMLFrom (pool, args->xml, clonevol, args->flags); + virStorageVolFree(clonevol); + virStoragePoolFree(pool); if (newvol == NULL) { remoteDispatchConnError(rerr, conn); return -1;
Hum, looks right, but how did you find this, valgrind the TCK ?
ACK
Daniel
Yes, with the TCK while running libvirtd under valgrind. Valgrind reported some of the hashes of a virConnectPtr leaking. I tracked it down to testcase 200, narrowed it further down by annotating the get, release and unref functions in datatypes.c and saw each call to virStorageVolCreateXMLFrom leaked a ref to the pool and the input volume. Looking at the code that is involved during a call to virStorageVolCreateXMLFrom revealed the problem. Okay, pushed. Matthias