# Valgrind suppressions for stuff that we cannot control
-# Memory leak in dash
-# dash is actually used when checking the "mkfile" command in tesh
+# Memory leaks in standard tools (e.g. dash, tail, or sort)
{
- Memory leak in /bin/dash
+ Memory leak in /bin tools
Memcheck:Leak
...
- obj:/bin/dash
+ obj:/bin/*
}
-# We also don't want to be annoyed by leaks in /usr/bin/tail
{
- Memory leak in /usr/bin/tail
+ Memory leak in /usr/bin tools
Memcheck:Leak
...
- obj:/usr/bin/tail
+ obj:/usr/bin/*
+}
+
+{
+ Memory leak in cmake
+ Memcheck:Leak
+ match-leak-kinds:reachable
+ ...
+ fun:_ZN4Json5Value13nullSingletonEv
+ obj:*/libjsoncpp.so*
+ ...
+ fun:_dl_init
}
# There's a constant leak of 56 bytes in the depths of libc which
fun:__libc_dlopen_mode
}
+# Another problem in glibc, where makecontext does not reset the EBP register,
+# and backtrace goes too far when walking up the stack frames
+{
+ Invalid read in backtrace, called after makecontext
+ Memcheck:Addr4
+ fun:backtrace
+ ...
+ fun:makecontext
+}
+
+#There seems to be an issue with libc using an uninitialized value somewhere in dlopen
+{
+ Invalid read in dl_start
+ Memcheck:Cond
+ fun:index
+ fun:expand_dynamic_string_token
+ ...
+ fun:_dl_start
+}
+
+# 72704 bytes leak from GCC >5.1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
+{
+ Memory leak in dl_init
+ Memcheck:Leak
+ match-leak-kinds:reachable
+ fun:malloc
+ obj:/usr/lib/*/libstdc++.so.*
+ fun:call_init.part.0
+ ...
+ fun:_dl_init
+}
+
+#Ignore leaks in SMPI sample codes
+{
+ Leaks in SMPI sample codes
+ Memcheck:Leak
+ match-leak-kinds: all
+ fun:malloc
+ fun:smpi_simulated_main_
+}
+
+#SMPI leaks the dlopen handle used to load the program
+{
+ dlopen handle leaks (1/3)
+ Memcheck:Leak
+ match-leak-kinds:reachable
+ fun:malloc
+ ...
+ fun:dlopen@@GLIBC_*
+}
+
+{
+ dlopen handle leaks (2/3)
+ Memcheck:Leak
+ match-leak-kinds:reachable
+ fun:calloc
+ ...
+ fun:dlopen@@GLIBC_*
+}
+
+{
+ dlopen handle leaks (3/3)
+ Memcheck:Leak
+ match-leak-kinds:reachable
+ fun:realloc
+ ...
+ fun:dlopen@@GLIBC_*
+}
+
# Memory leaks appearing to be in libcgraph. They can be seen with the
# following simple program:
# ,----
fun:aagparse
fun:agconcat
}
+{
+ Memory leak in libcgraph (1/2)
+ Memcheck:Leak
+ fun:calloc
+ ...
+ obj:/usr/lib/libcgraph.so*
+ fun:aagparse
+ fun:agconcat
+}
{
Memory leak in libcgraph (2/2)
Memcheck:Leak
fun:aagparse
fun:agconcat
}
+
+# We're not interested by memory leaks in the Lua interpreter
+{
+ Memory leak in lua
+ Memcheck:Leak
+ ...
+ fun:luaD_precall
+}
+
+# libunwind seems to be using msync poorly, thus triggering these
+# https://github.com/JuliaLang/julia/issues/4533
+{
+ msync unwind
+ Memcheck:Param
+ msync(start)
+ ...
+ obj:*/libpthread*.so
+ ...
+}
+
+{
+ ignore unwind cruft
+ Memcheck:Param
+ rt_sigprocmask(set)
+ ...
+ obj:/usr/lib/x86_64-linux-gnu/libunwind.so.*
+ ...
+}
+{
+ ignore unwind cruft
+ Memcheck:Param
+ msync(start)
+ ...
+ obj:/usr/lib/x86_64-linux-gnu/libunwind.so.*
+ ...
+}
+
+{
+ ignore unwind invalid reads
+ Memcheck:Addr8
+ fun:_Ux86_64_setcontext
+}
+
+# Java cruft
+{
+ JavaCruft 1
+ Memcheck:Addr4
+ ...
+ fun:_ZN9JavaCalls11call_helperEP9JavaValueP12methodHandleP17JavaCallArgumentsP6Thread
+ fun:JVM_DoPrivileged
+ ...
+}
+{
+ JavaCruft 2
+ Memcheck:Cond
+ ...
+ fun:_ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask
+ ...
+}
+
+{
+ Somewhere within the Java conditions and monitors
+ Memcheck:Cond
+ fun:MarsagliaXORV
+ ...
+}
+
+#ignore python cruft
+{
+ Memcheck:Cond
+ ...
+ obj:/usr/bin/python3
+}
+
+{
+ Memcheck:Addr4
+ ...
+ obj:/usr/bin/python3
+}
+
+{
+ Memcheck:Value8
+ ...
+ obj:/usr/bin/python3
+}
+
+
