Memory Checks
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!
Threading Checks
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 root.exe and valgrind will not report anything on root. The same options can of course be used when valgrinding your own programs!
CPU Profiling
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.
Why suppressions?
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.