[libvirt] [PATCH] Domain/Net object cleanups after remote error

Cole Robinson crobinso at redhat.com
Tue May 20 13:32:28 UTC 2008


Daniel P. Berrange wrote:
> On Tue, May 20, 2008 at 10:44:52AM +0100, Richard W.M. Jones wrote:
>> On Mon, May 19, 2008 at 04:58:38PM -0400, Cole Robinson wrote:
>>> diff --git a/src/remote_internal.c b/src/remote_internal.c
>>> index 51e8eb7..80f6ce6 100644
>>> --- a/src/remote_internal.c
>>> +++ b/src/remote_internal.c
>>> @@ -4606,6 +4606,10 @@ server_error (virConnectPtr conn, remote_error *err)
>>>                       err->str3 ? *err->str3 : NULL,
>>>                       err->int1, err->int2,
>>>                       "%s", err->message ? *err->message : NULL);
>>> +    if (dom)
>>> +        virDomainFree(dom);
>>> +    if (net)
>>> +        virNetworkFree(net);
>>>  }
>> Extra long hmmmmmmmmmmm ...
>>
>> This is right, the domain and network are leaked.
>>
>> However the virterror structure containing these pointers will be used
>> later.  (__virRaiseError saves it and callers access it later).
>>
>> However^2 these entries in the virterror structure are deprecated.  I
>> added a patch last month which adds a big warning about using these
>> entries.  At most callers should look at the pointers themselves and
>> shouldn't dereference them (which would be the only safe thing to do
>> given that the pointers have just been freed).
> 
> Yes, that should be safe - the only domain / network object set in an error
> condition is one that is passed in via the original caller. So there should
> still be a reference count held on these objects further up the call stack
> and thus this code won't actually free them immediately, merely decrement
> the ref count. Can probably confirm this by turning on debug mode and checking
> the messages.
> 
> Dan.

I just tested without this patch, but with the other destroy leak fixes I
sent, and everything looks to be okay. So this patch can be ignored.

Thanks,
Cole




More information about the libvir-list mailing list