[libvirt] clone memory leak and libvirt connection selection
Hi, I'm trying to use libvirt-0.6.5 within a multithreaded application without libvirtd and from what it looks like, it appears to have two things that are somewhat undesirable: 1) It tries to connect to libvirtd which isn't running. But it does eventually connect to the hypervisor. 2) It appears to leak some memory within a readonly connect and close. This is not too bad but it would be an issue in my long lived daemon application. I've attached an example program illustrating the issue with the linker log and the log from valgrind showing the memory leak. The code itself is based off the one on the website. Is there a URI I can use to avoid the connection to the libvirtd daemon while still connecting to the xendstore and is the memory leak an issue with the application environment or the library? Let me know if you need any more information. Thanks, Johnny
On Wed, Jul 22, 2009 at 09:32:31PM -0700, Johnny Luong wrote:
Hi,
I'm trying to use libvirt-0.6.5 within a multithreaded application without libvirtd and from what it looks like, it appears to have two things that are somewhat undesirable: 1) It tries to connect to libvirtd which isn't running. But it does eventually connect to the hypervisor.
That is expected - libvirtd should really always be running for Xen since it provides extra functionality not available from XenD, specifically virtual networking, network interfaces, storage pools and host devices.
2) It appears to leak some memory within a readonly connect and close. This is not too bad but it would be an issue in my long lived daemon application.
==13972== 400 bytes in 10 blocks are definitely lost in loss record 14 of 29 ==13972== at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==13972== by 0x6716CC9: (within /usr/lib/libxenstore.so.3.0.0) ==13972== by 0x6716E4F: (within /usr/lib/libxenstore.so.3.0.0) ==13972== by 0x6923FC6: start_thread (in /lib/libpthread-2.7.so) ==13972== by 0x51C35AC: clone (in /lib/libc-2.7.so) ==13972== This is a bug in the XenStore. It secretly spawns a background thread todo watch notifications, but when you close the xenstore handle it kills this thread without letting it clean up memory it has allocated. You can see this helpful message in the xs.c code in the xenstore library if (h->read_thr_exists) { /* XXX FIXME: May leak an unpublished message buffer. */ pthread_cancel(h->read_thr); pthread_join(h->read_thr, NULL); } Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Daniel P. Berrange -
Johnny Luong