Description of problem: 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) Version-Release number of selected component (if applicable): libvirt-0.10.0-0rc0.fc18.x86_64 How reproducible: 100% Steps to Reproduce: In libguestfs sources: cd ocaml ../run --test valgrind \ --vgdb=no --log-file=valgrind.log --leak-check=full --error-exitcode=119 \ --suppressions=../tests/extra/suppressions ./t/guestfs_005_load.bc
virInitialize is a one-time global initializer, so you must use the valgrind suppressions file to blacklist any stack trace below it.
Should we at least bundle a valgrind suppression file in the libvirt tarball to make it easier to ignore known one-time initializations?
(In reply to comment #2) > Should we at least bundle a valgrind suppression file in the libvirt tarball > to make it easier to ignore known one-time initializations? That sounds like a good idea to me. I'd really like to see us get to a silent valgrind run so that any further valgrind output could be cause for investigation.