2009/12/11 Daniel Veillard <veillard@xxxxxxxxxx>:
> 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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list