It seems as if this is just a variation on the previous libvirt
suppression.
==2042391== 61 (48 direct, 13 indirect) bytes in 1 blocks are definitely lost in
loss record 267 of 507
==2042391== at 0x4846464: calloc (vg_replace_malloc.c:1340)
==2042391== by 0x54EE318: g_malloc0 (gmem.c:163)
==2042391== by 0x5017D4C: virClassNew (virobject.c:189)
==2042391== by 0x523CCB9: virDataTypesOnce.lto_priv.0 (datatypes.c:111)
==2042391== by 0x4D8BE42: __pthread_once_slow (pthread_once.c:116)
==2042391== by 0x50345E1: virOnce (virthread.c:44)
==2042391== by 0x523CD6A: virGetConnect (datatypes.c:121)
==2042391== by 0x51FBC1F: virConnectOpenInternal (libvirt.c:893)
==2042391== by 0x51FCC11: virConnectOpenAuth (libvirt.c:1271)
==2042391== by 0x4A3ECAD: guestfs_int_open_libvirt_connection.constprop.0 (li
bvirt-auth.c:224)
==2042391== by 0x4A1D62A: launch_libvirt.lto_priv.0 (launch-libvirt.c:389)
==2042391== by 0x4993739: guestfs_launch (launch.c:114)
(cherry picked from guestfs-tools commit 8790af0266a808c8a04927bb5039be06cbc3da54)
OCaml PCRE.compile doesn't free up regexps if they are stored in
globals. However the valgrind suppression for this matched the old
function name, not the new PCRE2 name. Valgrind errors looked like:
==1799651== 145 bytes in 1 blocks are possibly lost in loss record 2,927 of 4,168
==1799651== at 0x484186F: malloc (vg_replace_malloc.c:381)
==1799651== by 0x4D5F2E5: pcre2_compile_8 (pcre2_compile.c:10250)
==1799651== by 0x29E077: guestfs_int_pcre_compile (pcre-c.c:196)
==1799651== by 0x2B725F: camlOVA__entry (OVA.ml:392)
==1799651== by 0x2859A8: caml_program (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40F9D8: caml_start_program (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40FD86: caml_startup_common (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x40FDDC: caml_startup (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
==1799651== by 0x28523F: main (in /home/rjones/d/virt-v2v/v2v/virt-v2v)
(cherry picked from virt-v2v commit 2949109ff9f7a081b1a4b475b9f7bcbef5b45ee0)
Run this command across the source:
perl -pi.bak -e 's/(20[012][0-9])-20[12][012]/$1-2023/g' `git ls-files`
and remove changes to po{,-docs}/*.po{,t} (these will be regenerated
later when we run 'make dist').
When running the OCaml bytecode tests, small but apparently
unimportant differences in the stack frames caused the existing
suppressions not to match. Adding an extra "..." will ignore these
differences allowing the tests to pass.
Valgrind output before this commit (note "UnknownInlinedFun" frame):
==1733400== 79 (48 direct, 31 indirect) bytes in 1 blocks are definitely lost in loss record 320 of 518
==1733400== at 0x484A464: calloc (vg_replace_malloc.c:1328)
==1733400== by 0x59685D0: g_malloc0 (gmem.c:136)
==1733400== by 0x531BB59: virClassNew (virobject.c:191)
==1733400== by 0x553A3BF: UnknownInlinedFun (datatypes.c:110)
==1733400== by 0x553A3BF: virDataTypesOnce (datatypes.c:121)
==1733400== by 0x49EA0C8: __pthread_once_slow (pthread_once.c:116)
==1733400== by 0x53312E9: virOnce (virthread.c:44)
==1733400== by 0x553A74A: UnknownInlinedFun (datatypes.c:121)
==1733400== by 0x553A74A: virGetConnect (datatypes.c:133)
==1733400== by 0x54FA94F: virConnectOpenInternal (libvirt.c:895)
==1733400== by 0x54FB883: virConnectOpenAuth (libvirt.c:1277)
==1733400== by 0x50E842A: guestfs_int_open_libvirt_connection.constprop.0 (libvirt-auth.c:224)
==1733400== by 0x50C6120: launch_libvirt.lto_priv.0 (launch-libvirt.c:390)
==1733400== by 0x5040E30: UnknownInlinedFun (launch.c:114)
==1733400== by 0x5040E30: guestfs_launch (actions-3.c:513)
==1733400==
==1733400== 256 bytes in 1 blocks are definitely lost in loss record 481 of 518
==1733400== at 0x484586F: malloc (vg_replace_malloc.c:381)
==1733400== by 0x137A0E: UnknownInlinedFun (memory.c:824)
==1733400== by 0x137A0E: caml_executable_name (unix.c:367)
==1733400== by 0x14C224: UnknownInlinedFun (startup_byt.c:502)
==1733400== by 0x14C224: caml_main (startup_byt.c:457)
==1733400== by 0x11CEE1: main (main.c:41)
As the name suggests, caml_stat* functions are used for allocating
static blocks. The OCaml runtime doesn't bother freeing any of these
on exit. OCaml 4.05 allocates caml_executable_name this way, a newly
seen global variable. We might as well just ignore everything
allocated this way.
Further information here:
e7cf3b1846/byterun/caml/memory.h (L66)
Run the following command over the source:
perl -pi.bak -e 's/(20[01][0-9])-2016/$1-2017/g' `git ls-files`
(Thanks Rich for the perl snippet, as used in past years.)
Valgrind has a weird hack where it invokes a glibc function called
__libc_freeres on exit. See:
http://valgrind.org/docs/manual/faq.html#faq.exit_errors
This is intended to free up memory that glibc won't normally free
(since glibc doesn't free everything on exit for efficiency reasons).
More importantly, valgrind runs __libc_freeres even if the process
calls _exit, resulting in this bug:
https://bugs.kde.org/show_bug.cgi?id=361810
(either a bug in valgrind, or in glibc, or in both, depending on your
point of view).
In any case we don't want this behaviour, so disable it.
Also we have to add suppressions for new "leaks" in glibc found by
valgrind because __libc_freeres no longer runs. In fact there is only
one such suppression needed, for TLS allocation in multithreaded
tests.
