I’m hunting for memory leaks in my applicantion with valgrind. There’s one leak that I’m not able to squash that comes out when I call TFile::GetObject (and also TFile::Get). The actual memory allocation is done in TStreamerInfo::Compile, as this valgrind trace shows:
==12560== 1,544 bytes in 1 blocks are possibly lost in loss record 34,712 of 34,804
==12560== at 0x4C28287: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12560== by 0x6B24EE2: TStreamerInfo::Compile() (in /home/mori/software/install/ROOT_5.34.10/lib/root/libRIO.so)
==12560== by 0x6B9BEE7: TStreamerInfo::BuildOld() (in /home/mori/software/install/ROOT_5.34.10/lib/root/libRIO.so)
==12560== by 0x6BDAC9F: TBufferFile::ReadClassBuffer(TClass const*, void*, int, unsigned int, unsigned int, TClass const*) (in /home/mori/software/install/ROOT_5.34.10/lib/root/libRIO.so)
==12560== by 0x84AFA6B: TTree::Streamer(TBuffer&) (in /home/mori/software/install/ROOT_5.34.10/lib/root/libTree.so)
==12560== by 0x6BCCA29: TKey::ReadObjectAny(TClass const*) (in /home/mori/software/install/ROOT_5.34.10/lib/root/libRIO.so)
==12560== by 0x6AECD5C: TDirectoryFile::GetObjectChecked(char const*, TClass const*) (in /home/mori/software/install/ROOT_5.34.10/lib/root/libRIO.so)
==12560== by 0x50992D0: void TDirectoryFile::GetObject<TTree>(char const*, TTree*&) (TDirectoryFile.h:82)
==12560== by 0x50988C1: GGSTRootReader::_FindTree(TString const&, TTree*&, TFile*&) (GGSTRootReader.cpp:68)
==12560== by 0x403FBD: GGSTHitsReader* GGSTRootReader::GetReader<GGSTHitsReader>(TString const&) (GGSTRootReader.h:162)
==12560== by 0x40390F: ProcessFolder(TString, TH2*, TH2*) (Analyze.cpp:81)
==12560== by 0x40362B: main (Analyze.cpp:34)Since I’m deleting the TTree that comes out of GetObject, and still valgrind reports the leak above, I thought that it might be somwhere inside the Root internals, but I don’t clearly understand what happens under the hood so I might be wrong. Also, this happens only when the read object is a TTree (no leak when getting a an object of a custom class of mine, for example).
The leak is not large so this may not be a big issue; I’m just reporting it in case some developer gets interested in it. Thanks.