[libvirt] Are they reasonable FD leaks?

Alex Jia ajia at redhat.com
Fri Feb 3 08:04:41 UTC 2012


If you're using libvirt upstream to check it, you need to revoke
commit 6152c74, which fixed memory leak issue on cmdUndefine(), 
it's okay without FD leaks if memory leak is fixed, in other
words, you will met FD leaks if you saw the following similar
error information:

error: Failed to disconnect from the hypervisor, 1 leaked reference(s)

Regards,
Alex

----- Original Message -----
From: "Alex Jia" <ajia at redhat.com>
To: "libvir" <libvir-list at redhat.com>
Sent: Friday, February 3, 2012 3:54:43 PM
Subject: [libvirt]  Are they reasonable FD leaks?

Hi all,
I met some FD leaks when I tried the following scenario:

% dd if=/dev/null of=/var/lib/libvirt/images/foo bs=1 count=1 seek=10M
% virsh define foo.xml                   (disk source file points to '/var/lib/libvirt/images/foo')
% virsh vol-clone foo foo-clone default  (the original guest name is 'foo') 
% virsh pool-refresh default
% virsh vol-list default                 (make sure 'foo-clone' volume exists)
% virsh define foo-clone.xml             (disk source file points to '/var/lib/libvirt/images/foo-clone')
% valgrind -v --track-fds=yes virsh undefine foo-clone --remove-all-storage

<snip>

==21003== FILE DESCRIPTORS: 10 open at exit.
==21003== Open file descriptor 9:
==21003==    at 0x39CF0D8BB7: pipe2 (in /lib64/libc-2.12.so)
==21003==    by 0x4E4FC97: rpl_pipe2 (pipe2.c:59)
==21003==    by 0x4D5C3FA: virNetClientNew (virnetclient.c:278)
==21003==    by 0x4D5C7B2: virNetClientNewUNIX (virnetclient.c:352)
==21003==    by 0x4D47EAA: doRemoteOpen (remote_driver.c:601)
==21003==    by 0x4D499AF: remoteOpen (remote_driver.c:873)
==21003==    by 0x4D12D23: do_open (libvirt.c:1196)
==21003==    by 0x4D13EE5: virConnectOpenAuth (libvirt.c:1422)
==21003==    by 0x415040: vshReconnect (virsh.c:637)
==21003==    by 0x4152A7: vshCommandRun (virsh.c:17688)
==21003==    by 0x4264D3: main (virsh.c:19270)
==21003==
==21003== Open file descriptor 8:
==21003==    at 0x39CF0D8BB7: pipe2 (in /lib64/libc-2.12.so)
==21003==    by 0x4E4FC97: rpl_pipe2 (pipe2.c:59)
==21003==    by 0x4D5C3FA: virNetClientNew (virnetclient.c:278)
==21003==    by 0x4D5C7B2: virNetClientNewUNIX (virnetclient.c:352)
==21003==    by 0x4D47EAA: doRemoteOpen (remote_driver.c:601)
==21003==    by 0x4D499AF: remoteOpen (remote_driver.c:873)
==21003==    by 0x4D12D23: do_open (libvirt.c:1196)
==21003==    by 0x4D13EE5: virConnectOpenAuth (libvirt.c:1422)
==21003==    by 0x415040: vshReconnect (virsh.c:637)
==21003==    by 0x4152A7: vshCommandRun (virsh.c:17688)
==21003==    by 0x4264D3: main (virsh.c:19270)
==21003==
==21003== Open AF_UNIX socket 7: <unknown>
==21003==    at 0x39CF0E67B7: socket (in /lib64/libc-2.12.so)
==21003==    by 0x4D6B0F0: virNetSocketNewConnectUNIX (virnetsocket.c:490)
==21003==    by 0x4D5C79F: virNetClientNewUNIX (virnetclient.c:349)
==21003==    by 0x4D47EAA: doRemoteOpen (remote_driver.c:601)
==21003==    by 0x4D499AF: remoteOpen (remote_driver.c:873)
==21003==    by 0x4D12D23: do_open (libvirt.c:1196)
==21003==    by 0x4D13EE5: virConnectOpenAuth (libvirt.c:1422)
==21003==    by 0x415040: vshReconnect (virsh.c:637)
==21003==    by 0x4152A7: vshCommandRun (virsh.c:17688)
==21003==    by 0x4264D3: main (virsh.c:19270)

</snip>

It seems libvirt deliberately leaks these FDs, right?

Regards,
Alex

--
libvir-list mailing list
libvir-list at redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list