2009/12/11 Daniel Veillard <veillard(a)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