Reduces the amount of build env leaked in the binaries (see #39)

[simgrid.git] / tools / simgrid.supp

# Valgrind suppressions for stuff that we cannot control

# Memory leaks in standard tools (e.g. dash, tail, or sort)
{
   Memory leak in /bin tools
   Memcheck:Leak
   ...
   obj:/bin/*
}

{
   Memory leak in /usr/bin tools
   Memcheck:Leak
   ...
   obj:/usr/bin/*
}

{
   Memory leak in cmake
   Memcheck:Leak
   ...
   obj:cmake
}

# There's a constant leak of 56 bytes in the depths of libc which
# manifests, for example, when using backtrace()
{
   Memory leak in libc/dlopen with -pthread
   Memcheck:Leak
   fun:malloc
   fun:_dl_map_object_deps
   fun:dl_open_worker
   fun:_dl_catch_error
   fun:_dl_open
   fun:do_dlopen
   fun:_dl_catch_error
   fun:dlerror_run
   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/2)
   Memcheck:Leak
   match-leak-kinds:reachable
   fun:malloc
   ...
   fun:dlopen@@GLIBC_*
}

{
   dlopen handle leaks (2/2)
   Memcheck:Leak
   match-leak-kinds:reachable
   fun:calloc
   ...
   fun:dlopen@@GLIBC_*
}

# Memory leaks appearing to be in libcgraph.  They can be seen with the
# following simple program:
# ,----
# | #include <stdio.h>
# | #include <graphviz/cgraph.h>
# | int main(int argc, char *argv[])
# | {
# |     if (argc == 1) {
# |         printf("Usage: %s <dotfile>\n", argv[0]);
# |         return 1;
# |     }
# |     Agraph_t *g;
# |     FILE *inf = fopen(argv[1], "r");
# |     g = agread(inf, 0);
# |     fclose(inf);
# |     agclose(g);
# |     return 0;
# | }
# `----
{
   Memory leak in libcgraph (1/2)
   Memcheck:Leak
   fun:malloc
   ...
   obj:/usr/lib/libcgraph.so*
   fun:aaglex
   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:malloc
   ...
   fun:agnode
   obj:/usr/lib/libcgraph.so*
   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
   ...
}