[libvirt] Availability of 0.9.4 candidate release 2 rc1

[Wen Congyang]

At 08/01/2011 06:02 PM, Matthias Bolte write:
> 2011/8/1 Wen Congyang<wency at cn.fujitsu.com>:
>> At 07/30/2011 03:02 PM, Daniel Veillard Write:
>>> I actually tagged and pushed the rc2 tarball and rpms yesterday
>>> but completely forgot to send the associated mail, oops !
>>>
>>>     ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
>>>
>>> Hopefully it fixes most of the problems raised with rc1, including
>>> a number of leaks. Please report and if you had an issue with rc1
>>> which is still not fixed there (or in git) please raise it ASAP.
>>> I'm planning for the final release early Tuesday 2 morning (i.e.
>>> late Monday for most :-)
>>
>> If client(for example: virsh) exits unexpectedly, it will cause libvirtd
>> crashed.
>>
>> Steps to reproduce this problem(vm1 does not run):
>> 1. for ((i=0; i<  50; i++)); do virsh managedsave vm1&  done; killall virsh
>>
>> The reason is that we free virNetServerClient when the refs is not 0.
>
> I'm not sure what you mean here. virNetClientFree frees the client
> when the last ref is removed.
>
>> I read the code under the directory src/rpc/, and find we have xxxRef(), but
>> we do not have xxxUnref(). And sometimes we free the data structure if ref is
>> not 0. We add an reference of the data structure, but sometimes we forget to
>> unref it.
>
> We already have an unref function it's called virNetClientFree.

Sorry for confusing you.

The reason is that:
In the function virNetServerClientClose(), we set client->sock to NULL 
while we still use it.

Thanks.

Wen Congyang

>
> Are you referring to virNetClientClose that closes the connection and
> frees parts of the client?
>
> I tried to figure out the cleanup and ref counting logic in the RPC
> code in order to fix a memory leak triggered by virsh.
>
> https://www.redhat.com/archives/libvir-list/2011-July/msg02011.html
>
> It's complex and I don't understand it completely, as there is ref
> counting on multiple levels that is entangled with the event loop.
>