[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
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@redhat.com> To: "libvir" <libvir-list@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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Feb 03, 2012 at 03:04:41AM -0500, Alex Jia wrote:
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)
This is a sign of some code failing to unref the virStoragePoolPtr or virStorageVolPtr or virConnectPtr object.
It seems libvirt deliberately leaks these FDs, right?
I don't think that is delibrate. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 02/03/2012 06:25 PM, Daniel P. Berrange wrote:
On Fri, Feb 03, 2012 at 03:04:41AM -0500, Alex Jia wrote:
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:
The memory leak fixed in 6152c74 is a leak of a virStorageVolPtr reference/pointer that also caused the FD leak. While referenced, the storage driver holds a FD to the image identified with the virStorageVolPtr.
error: Failed to disconnect from the hypervisor, 1 leaked reference(s)
This is a sign of some code failing to unref the virStoragePoolPtr or virStorageVolPtr or virConnectPtr object.
It seems libvirt deliberately leaks these FDs, right?
I don't think that is delibrate.
The leak is not deliberate. It's caused by not freeing the reference. (Bug). Peter
Daniel
Daniel and Peter, thanks. Alex ----- Original Message ----- From: "Peter Krempa" <pkrempa@redhat.com> To: "Daniel P. Berrange" <berrange@redhat.com> Cc: "Alex Jia" <ajia@redhat.com>, "libvir" <libvir-list@redhat.com> Sent: Monday, February 6, 2012 8:57:51 PM Subject: Re: [libvirt] Are they reasonable FD leaks? On 02/03/2012 06:25 PM, Daniel P. Berrange wrote:
On Fri, Feb 03, 2012 at 03:04:41AM -0500, Alex Jia wrote:
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:
The memory leak fixed in 6152c74 is a leak of a virStorageVolPtr reference/pointer that also caused the FD leak. While referenced, the storage driver holds a FD to the image identified with the virStorageVolPtr.
error: Failed to disconnect from the hypervisor, 1 leaked reference(s)
This is a sign of some code failing to unref the virStoragePoolPtr or virStorageVolPtr or virConnectPtr object.
It seems libvirt deliberately leaks these FDs, right?
I don't think that is delibrate.
The leak is not deliberate. It's caused by not freeing the reference. (Bug). Peter
Daniel
participants (3)
-
Alex Jia -
Daniel P. Berrange -
Peter Krempa