[libvirt] ruby-libvirt issue

[Matthias Bolte]

2010/11/24 Matthias Bolte <matthias.bolte at googlemail.com>:
> 2010/11/24 Paweł Krześniak <pawel.krzesniak at gmail.com>:
>> On Tue, Nov 23, 2010 at 14:28, Chris Lalancette <clalance at redhat.com> wrote:
>>> In terms of making this automatically happen during connection closing, I'm
>>> not entirely sure what we can (and should) do.  I guess we could keep some sort
>>> of list of objects that "depend" on this connection object, and then during
>>> connection close  free them all up. Does anyone know how the python bindings
>>> handle this?
>>
>> python bindings work more or less the same way (see attachment).
>>
>> So conclusion is, that all objects must be free() before closing connection.
>> It's not so intuitive, so maybe info about that should be somewhere in docs?
>>
>
> Actually it is supposed to work correctly as long as you match every
> virConnectOpen* call with a virConnectFree call and each call that
> returns a virDomainPtr, virStorageVolPtr etc with the corresponding
> free call. It should not matter in which order you call the close/free
> functions, the internal refcounting should make it work.
>
> Obviously the order seems to matter regarding the output of "netstat
> -na | grep -v LISTENING | grep -c libvirt-sock". The problem is not in
> the Python or Ruby bindings as I can reproduce it using the C API
> (current git version). This might indicate a problem in libvirt.
>
> I attached the test program. With NORMAL_ORDER = 1 the initial value
> stays the same, with NORMAL_ORDER = 0 it grows by 1 per iteration.
>
> Matthias
>

Okay, I found it. The problem with the "non-normal" order is that
libvirt will miss to close the open drivers when virConnectClose isn't
the one that removes the last ref from the connection. This results in
the remote driver keeping the handle to the libvirt-sock open.

I just posted a patch that fixes this problem:

https://www.redhat.com/archives/libvir-list/2010-November/msg01105.html

Matthias