[libvirt] Memory leak in virInitialize -> vboxRegister -> VBoxCGlueInit
https://bugzilla.redhat.com/show_bug.cgi?id=847429 Spotted by valgrind: ==2390== 45 bytes in 1 blocks are definitely lost in loss record 68 of 123 ==2390== at 0x4A086DC: malloc (vg_replace_malloc.c:270) ==2390== by 0x30D060EBA0: _dl_signal_error (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D0612CF2: _dl_open (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D1601025: dlopen_doit (in /usr/lib64/libdl-2.16.so) ==2390== by 0x30D060EDC5: _dl_catch_error (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D160163B: _dlerror_run (in /usr/lib64/libdl-2.16.so) ==2390== by 0x30D16010C0: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.16.so) ==2390== by 0x5893994: tryLoadOne (vbox_XPCOMCGlue.c:127) ==2390== by 0x5893BE2: VBoxCGlueInit (vbox_XPCOMCGlue.c:230) ==2390== by 0x589407F: vboxRegister (vbox_driver.c:88) ==2390== by 0x5817568: virInitialize (libvirt.c:450) ==2390== by 0x5492C02: init_libguestfs (guestfs.c:108) libvirt-0.10.0-0rc0.fc18.x86_64 libguestfs calls virInitialize, but (since there is no cleanup function) doesn't do any corresponding cleanup. Is that correct? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Sat, Aug 11, 2012 at 07:45:19AM +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=847429
Spotted by valgrind:
==2390== 45 bytes in 1 blocks are definitely lost in loss record 68 of 123 ==2390== at 0x4A086DC: malloc (vg_replace_malloc.c:270) ==2390== by 0x30D060EBA0: _dl_signal_error (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D0612CF2: _dl_open (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D1601025: dlopen_doit (in /usr/lib64/libdl-2.16.so) ==2390== by 0x30D060EDC5: _dl_catch_error (in /usr/lib64/ld-2.16.so) ==2390== by 0x30D160163B: _dlerror_run (in /usr/lib64/libdl-2.16.so) ==2390== by 0x30D16010C0: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.16.so) ==2390== by 0x5893994: tryLoadOne (vbox_XPCOMCGlue.c:127) ==2390== by 0x5893BE2: VBoxCGlueInit (vbox_XPCOMCGlue.c:230) ==2390== by 0x589407F: vboxRegister (vbox_driver.c:88) ==2390== by 0x5817568: virInitialize (libvirt.c:450) ==2390== by 0x5492C02: init_libguestfs (guestfs.c:108)
libvirt-0.10.0-0rc0.fc18.x86_64
libguestfs calls virInitialize, but (since there is no cleanup function) doesn't do any corresponding cleanup. Is that correct?
Yep, virInitialize does global one-time initialization and we don't provide any de-initialization function, so any memory allocations should be considered global state. You'll want to provide a valgrind suppressions file which whitelists any stack trace below the virInitialize function. Regards, 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 08/13/2012 01:57 AM, Daniel P. Berrange wrote:
On Sat, Aug 11, 2012 at 07:45:19AM +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=847429
Spotted by valgrind:
==2390== 45 bytes in 1 blocks are definitely lost in loss record 68 of 123
==2390== by 0x5817568: virInitialize (libvirt.c:450) ==2390== by 0x5492C02: init_libguestfs (guestfs.c:108)
libvirt-0.10.0-0rc0.fc18.x86_64
libguestfs calls virInitialize, but (since there is no cleanup function) doesn't do any corresponding cleanup. Is that correct?
Yep, virInitialize does global one-time initialization and we don't provide any de-initialization function, so any memory allocations should be considered global state. You'll want to provide a valgrind suppressions file which whitelists any stack trace below the virInitialize function.
Should libvirt be providing a suppression file as part of the installation to make it easier for others to ignore known one-shot initializations? -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Aug 13, 2012 at 09:53:22AM -0600, Eric Blake wrote:
On 08/13/2012 01:57 AM, Daniel P. Berrange wrote:
On Sat, Aug 11, 2012 at 07:45:19AM +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=847429
Spotted by valgrind:
==2390== 45 bytes in 1 blocks are definitely lost in loss record 68 of 123
==2390== by 0x5817568: virInitialize (libvirt.c:450) ==2390== by 0x5492C02: init_libguestfs (guestfs.c:108)
libvirt-0.10.0-0rc0.fc18.x86_64
libguestfs calls virInitialize, but (since there is no cleanup function) doesn't do any corresponding cleanup. Is that correct?
Yep, virInitialize does global one-time initialization and we don't provide any de-initialization function, so any memory allocations should be considered global state. You'll want to provide a valgrind suppressions file which whitelists any stack trace below the virInitialize function.
Should libvirt be providing a suppression file as part of the installation to make it easier for others to ignore known one-shot initializations?
Is there a way for individual libraries to register global suppression files with valgrind ? If so, then I think it'd be reasonable for us to supply one. Otherwise, we could at least stuff one in the docs directory 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 :|
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Richard W.M. Jones