ROOT triggers a couple of valgrind reports that are intentional (see below if you care why). To suppress those use the following invocation:
valgrind --num-callers=30 --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe -l -b -q myscript.C
Note: yes, really
root.exe, even on Linux and macOS!
tbb (used by ROOT) is confusing helgrind; this is a known issue. To suppress these known false-positives, please use
valgrind --tool=helgrind --suppressions=$ROOTSYS/etc/helgrind-root.supp ./myMultithreadedProgram
Please run valgrind on
root.exe, also on Linux:
root is a tiny wrapper around
valgrind will not report anything on
root. The same options can of course be used when
valgrinding your own programs!
You can invoke
valgrind --tool=callgrind --fn-skip=_dl_runtime_resolve_avx root.exe -l -b -q myScript.C+ to see where the time is spent. The
--fn-skip argument avoids circles (A calls B calls C calls A) that are synthetic due to shared library symbol lookup; the actual function name might differ, its
_avx version is common on current Intel architectures.
TObject-derived classes are tagging heap allocated memory to determine heap versus stack allocations, which triggers reports in valgrind. cling tries to read from pointers even if the memory they point to hasn’t been initialized, to report invalid pointers instead of crashing. And lastly, ROOT’s meta-classes (
TClass and friends) are providing data even at process shutdown time, when ROOT writes
TFiles that are still open. To “survive” this phase, ROOT intentionally keeps meta objects alive. This is not a problem because we simply delay the deletion of these objects until the real end of the program: the kernel will take care of it.