Memory leak in MakeProxy code in 5.14?

ROOT
1

Hi,
Are there known memory leak problems in MakeProxy in 5.14? I’ve got a pretty basic TTree - it contains lots of vector’s, and at worst some vector<vector >'s. When I run I get a huge memory leak according to valgrind:

==14978== by 0x41F7616: std::_Vector_base<char, std::allocator >::_M_allocate(unsigned) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F743F: std::vector<char, std::allocator >::_M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator > >, unsigned, char const&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F7307: std::vector<char, std::allocator >::insert(__gnu_cxx::__normal_iterator<char*,
std::vector<char, std::allocator > >, unsigned, char const&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F5182: TEmulatedCollectionProxy::Expand(unsigned, unsigned) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F54B6: TEmulatedCollectionProxy::Resize(unsigned, bool) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F6075: TEmulatedCollectionProxy::Streamer(TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F2B2B: TCollectionStreamer::Streamer(TBuffer&, void*, int) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F2E16: TCollectionClassStreamer::operator()(TBuffer&, void*) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x422786F: TClass::Streamer(void*, TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x414ECC4: TBuffer::StreamObject(void*, TClass const*) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F5885: TEmulatedCollectionProxy::ReadItems(int, TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F608D: TEmulatedCollectionProxy::Streamer(TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F2B2B: TCollectionStreamer::Streamer(TBuffer&, void*, int) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x41F2E16: TCollectionClassStreamer::operator()(TBuffer&, void*) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x422786F: TClass::Streamer(void*, TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x414C8FC: TBuffer::ReadFastArray(void*, TClass const*, int, TMemberStreamer*) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x42636AE: int TStreamerInfo::ReadBuffer<char**>(TBuffer&, char** const&, int, int, int, int) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libCore.so)
==14978== by 0x48538CA: TBranchElement::ReadLeaves(TBuffer&) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libTree.so)
==14978== by 0x4844502: TBranch::GetEntry(long long, int) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libTree.so)
==14978== by 0x4850BD9: TBranchElement::GetEntry(long long, int) (in /atlinux/cernSL/root/root_v5.14.00e_SL4/lib/libTree.so)
==14978== by 0x80526FC: ROOT::TBranchProxy::Read() (in /atlas/watts/analysis/cscWork/code/gwatts/CSCDiJetStudies/bin/RunMuonAnalysis)
==14978== by 0x804EAA7: MuonStudy::doit() (in /atlas/watts/analysis/cscWork/code/gwatts/CSCDiJetStudies/bin/RunMuonAnalysis)
==14978== by 0x8052E43: CollectionTreeProxy::Process(long long) (in /atlas/watts/analysis/cscWork/code/gwatts/CSCDiJetStudies/bin/RunMuonAnalysis)

Is this a known problem? Is there anything I can do to work around it without totally leaving the MakeProxy approach? I don’t know if it is present in the latest version because I can’t use it yet (MakeProxy doesn’t work in 5.17/08).

Cheers,
Gordon.

2

Gordon,

Why do you claim that this is a leak? In emulated mode, ROOT has to allocate a storage area for your vectors.

Rene

3

I claim it is a leak because the more events I run the larger the total size allocated at this point is. Eventually, the process runs out of memory (after about 200K events). It is as if it doesn’t clear what it allocates after each event.

This smells very similar to a leak I encountered ages ago - when I had a TClonesArray that had objects that allocated memory of their own - tha twas released in the dtor. I can to call something on each TClonesArray branch at the end of each iteration to make sure every object’s dtor was properly called.

For example, here I have vector<vector > - so could that be the problem? I only thought of this as I was getting up this morning, so I’ve not had a chance to test it.

Cheers,
Gordon.

4

Hi,

This leak is resolved in the SVN trunk.

Thanks for reporting this issue.

Philippe.

5

And thanks for the fast response in fixing it! -Gordon.