Re: Memory Leaks due to SetBranchAddress()

Hi,

It looks like you will need to add a delete for the pointer to vector. The delete needs to be in the same Terminate function or in the destructor.

Cheers,
Philippe.

On 1/27/11 9:39 AM, Hovhannes Khandanyan wrote:
> Dear ROOTers,
>
> I am using MakeClass() to read my analysis ntuple. While cheching for memory leaks with valgrind I saw multiple memory leaks due to TChain::SetBranchAddress():
>
> ==15038== 156 (12 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss record 50,046 of 53,952
> ==15038== at 0x4C8A080: operator new(unsigned int) (vg_replace_malloc.c:214)
> ==15038== by 0x824BC53: ROOT::new_vectorlEfloatgR(void*) (YNtuple_dict.cc:198)
> ==15038== by 0x5099B1A: TClass::New(TClass::ENewType) const (in /afs/cern.ch/atlas/software/releases/16.0.3/sw/lcg/app/releases/ROOT/5.26.00e_python2.6/i686-slc5-gcc43-opt/root/lib/libCore.so)
> ==15038== by 0xA662C10: TBranchElement::SetAddress(void*) (in /afs/cern.ch/atlas/software/releases/16.0.3/sw/lcg/app/releases/ROOT/5.26.00e_python2.6/i686-slc5-gcc43-opt/root/lib/libTree.so)
> ==15038== by 0xA677294: TChain::SetBranchAddress(char const*, void*, TBranch**) (in /afs/cern.ch/atlas/software/releases/16.0.3/sw/lcg/app/releases/ROOT/5.26.00e_python2.6/i686-slc5-gcc43-opt/root/lib/libTree.so)
> ==15038== by 0xA67707C: TChain::SetBranchAddress(char const*, void*, TBranch**, TClass*, EDataType, bool) (in /afs/cern.ch/atlas/software/releases/16.0.3/sw/lcg/app/releases/ROOT/5.26.00e_python2.6/i686-slc5-gcc43-opt/root/lib/libTree.so)
> ==15038== by 0x8328A4D: int TTree::SetBranchAddress<std::vector<float, std::allocator<float> > >(char const*, std::vector<float, std::allocator<float> >**, TBranch**) (TTree.h:394)
> ==15038== by 0x8321F4A: YNtuple::Init(TTree*) (YNtuple.hh:1701)
> ==15038== by 0x83286AC: YNtuple::YNtuple(TTree*, int) (YNtuple.hh:1176)
> ==15038== by 0x82932C7: TAnaModule::TAnaModule(TTree*, std::string, int) (TAnaModule.cc:75)
> ==15038== by 0x80DFAA5: main (YAnalysis.cc:394)
>
> Please let me know if there is a remedy for this.
>
> The complete valgrind report can be found here:
> afs/cern.ch/user/k/khandan/public/atlas/yframework/code/BigLoop.out
>
> The YNtuple.hh can be accessed here:
> /afs/cern.ch/user/k/khandan/public/atlas/yframework/code/yntuple/yntuple/YNtuple.hh
>
> /afs/cern.ch/atlas/software/releases/16.0.3/sw/lcg/app/releases/ROOT/5.26.00e_python2.6/i686-slc5-gcc43-opt/root
>
> Thanks,
> Hovhannes
>
>
>
Received on Thu Jan 27 2011 - 17:00:42 CET