[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] virNetClientPtr leak in remote driver

On 07/28/2011 12:07 PM, Matthias Bolte wrote:
> 2011/7/27 Matthias Bolte <matthias bolte googlemail com>:
>> doRemoteClose doesn't free the virNetClientPtr and this creates a
>> 260kb leak per remote connection. This happens because
>> virNetClientFree doesn't remove the last ref, because virNetClientNew
>> creates the virNetClientPtr with a refcount of 2.

> The memory leak I saw was due to virsh calling
> virEventRegisterDefaultImpl, but not calling virEventRunDefaultImpl.
> Because the event loop is initialized, the call to
> virNetSocketAddIOCallback in virNetClientNew succeeds. But virsh not
> driving the event loop results in not removing callbacks that were
> marked for deletion. Finally this leaks the virNetClientPtr using in
> the remote driver. I used a virsh -c qemu:///system to test.
> I was able fix this by calling virEventRunDefaultImpl after
> virConnectClose in virsh. But I don't think that this is the correct
> general solution.

Where do we stand with 0.9.4?  Is this something where we need the
general fix before the release, or is just the virsh hack to call
virEventRunDefaultImpl good enough for the release, or is this problem
not severe enough and we can release as-is?

> To me the general problem seems to be the entanglement between the
> virNetClientPtr refcounting and the event loop. I'm not sure how to
> improve this in general. Maybe should have a thread calling
> virEventRunDefaultImpl as the comment on virEventRunDefaultImpl
> suggest.

I'm hoping danpb will be able to chime in soon.

Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]