Memory Checker

To make sure there are no memory leaks, or to check if there are invalid access to memory use vagrind

• Install an up-to-date version of valgrind via the latest version of the devtoolsets http://linux.web.cern.ch/linux/devtoolset/

• Run valgrind. For example to run Marlin inside valgrind:

/opt/rh/devtoolset-4/root/usr/bin/valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp --show-reachable=yes --leak-check=full Marlin clicReconstruction.xml

Here we are also ignoring known memory issues inside root.

Understanding the output:

1. The messages from valgrind are sorted by the most important at the bottom
2. Summary at the end:

==20824== LEAK SUMMARY:
==20824==    definitely lost: 14,609,320 bytes in 250,478 blocks
==20824==    indirectly lost: 14,583,264 bytes in 262,418 blocks
==20824==      possibly lost: 8,164,396 bytes in 123,851 blocks
==20824==    still reachable: 91,334,258 bytes in 473,577 blocks
==20824==         suppressed: 537,986 bytes in 6,334 blocks

This means that (as far as valgrind is able to tell) there are about

• 15 MB of memory lost definitely: e.g.: new without any delete
• 16 MB lost indirectly: probably lost bcause an object keeps resources that would be freed if the object were to be cleaned
• 8 MB possibly lost: well, maybe or maybe not
• 91 MB can still be reached at the end of program execution, but is not explicitly cleaned up

Detailed output

==20824== 15,165,140 (5,215,128 direct, 9,950,012 indirect) bytes in 217,297 blocks are definitely lost in loss record 19,291 of 19,291
==20824==    at 0x4A08E83: operator new(unsigned long) (in /opt/rh/devtoolset-4/root/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20824==    by 0xB5920FA: ConformalTracking::createTracksNew(std::vector<std::vector<Cell*, std::allocator<Cell*> >*, std::allocator<std::vector<Cell*, std::allocator<Cell*> >*> >&, Cell*, std::map<Cell*, bool, std::less<Cell*>, std::allocator<std::pair<Cell* const, bool> > >&) (ConformalTracking.cc:1287)
==20824==    by 0xB597273: ConformalTracking::processEvent(EVENT::LCEvent*) (ConformalTracking.cc:799)
==20824==    by 0x60BB8FB: marlin::ProcessorMgr::processEvent(EVENT::LCEvent*) (ProcessorMgr.cc:475)
==20824==    by 0x4CBBD0C: SIO::SIOReader::readStream(int) (SIOReader.cc:732)
==20824==    by 0x4128DF: main (Marlin.cc:489)

15 MB lost by calling new in line 1287 of the file ConformalTracking.cc in the function createNewTracks, which is called in CoformalTracking.cc line 799 in function processEvent, and so on Look at line 1287 and try to follow the objects created there until their pointer goes out of scope.

Valgrind massif memory monitoring

The massif tool of valgrind monitors memory use over time

/opt/rh/devtoolset-4/root/usr/bin/valgrind --tool=massif Marlin clicReconstruction.xml --Config.Tracking=Conformal --global.MaxRecordNumber=100
...
ms_print massif.out.<PID>

Debugger

To run the debugger (in order to see exceptions, investigate crashes, etc.) simply start Marlin with gdb:

gdb Marlin

Then from within the prompt you can run your xml options file:

run clicReconstruction.xml

If the symbols are not recognized properly, check you are using one of the latest gdb version, such as

 /cvmfs/sft.cern.ch/lcg/external/gdb/7.6/x86_64-slc6-gcc48-opt/bin/gdb

GDB in Emacs

-- AndreSailer - 2016-11-07