[RF] "Definitely lost" reported by Valgrind in RooAbsCollection

[TomasDado]

Explain what you would like to see improved and how.

Running valgrind reports this memory leak:

==41074== 5,528 (72 direct, 5,456 indirect) bytes in 1 blocks are definitely lost in loss record 16,046 of 16,872
==41074==    at 0x4848F95: operator new(unsigned long) (vg_replace_malloc.c:487)
==41074==    by 0x5AE6A13: RooAbsCollection::find(char const*) const (RooAbsCollection.cxx:932)
==41074==    by 0x5D71B86: RooWorkspace::import(RooAbsArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&) (RooWorkspace.cxx:665)
==41074==    by 0x7553342: RooStats::HistFactory::HistoToWorkspaceFactoryFast::MakeCombinedModel(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::vector<std::unique_ptr<RooWorkspace, std::default_delete<RooWorkspace> >, std::allocator<std::unique_ptr<RooWorkspace, std::default_delete<RooWorkspace> > > >&) (HistoToWorkspaceFactoryFast.cxx:1565)
==41074==    by 0x4B72C77: TRExFit::PerformWorkspaceCombination(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) const (TRExFit.cc:5014)
==41074==    by 0x4BF32E3: TRExFit::PrepareMixedDataset(TRExFit::WorkspaceType) (TRExFit.cc:10421)
==41074==    by 0x4C01732: TRExFit::Fit(bool) (TRExFit.cc:4338)
==41074==    by 0x115524: FitExample(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (trex-fitter.cc:473)
==41074==    by 0x10FE1E: main (trex-fitter.cc:696)

The relavant line uses raw pointers so it looks like the leak might be real.

Potentially a related stack trace:

==41472== 2,400 bytes in 100 blocks are indirectly lost in loss record 16,476 of 17,809
==41472==    at 0x4848F95: operator new(unsigned long) (vg_replace_malloc.c:487)
==41472==    by 0x5AEDE53: allocate (new_allocator.h:151)
==41472==    by 0x5AEDE53: allocate (alloc_traits.h:478)
==41472==    by 0x5AEDE53: _M_allocate_node<const TNamed*, RooAbsArg* const&> (hashtable_policy.h:2019)
==41472==    by 0x5AEDE53: _Scoped_node<const TNamed*, RooAbsArg* const&> (hashtable.h:312)
==41472==    by 0x5AEDE53: _M_emplace<const TNamed*, RooAbsArg* const&> (hashtable.h:2143)
==41472==    by 0x5AEDE53: emplace<const TNamed*, RooAbsArg* const&> (hashtable.h:1001)
==41472==    by 0x5AEDE53: emplace<const TNamed*, RooAbsArg* const&> (unordered_map.h:396)
==41472==    by 0x5AEDE53: RooFit::Detail::HashAssistedFind::HashAssistedFind<__gnu_cxx::__normal_iterator<RooAbsArg* const*, std::vector<RooAbsArg*, std::allocator<RooAbsArg*> > > >(__gnu_cxx::__normal_iterator<RooAbsArg* const*, std::vector<RooAbsArg*, std::allocator<RooAbsArg*> > >, __gnu_cxx::__normal_iterator<RooAbsArg* const*, std::vector<RooAbsArg*, std::allocator<RooAbsArg*> > >) (RooAbsCollection.cxx:76)
==41472==    by 0x5AE6A26: RooAbsCollection::find(char const*) const (RooAbsCollection.cxx:932)
==41472==    by 0x5D71B86: RooWorkspace::import(RooAbsArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&, RooCmdArg const&) (RooWorkspace.cxx:665)
==41472==    by 0x7553342: RooStats::HistFactory::HistoToWorkspaceFactoryFast::MakeCombinedModel(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::vector<std::unique_ptr<RooWorkspace, std::default_delete<RooWorkspace> >, std::allocator<std::unique_ptr<RooWorkspace, std::default_delete<RooWorkspace> > > >&) (HistoToWorkspaceFactoryFast.cxx:1565)
==41472==    by 0x4B72C77: TRExFit::PerformWorkspaceCombination(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) const (TRExFit.cc:5014)
==41472==    by 0x4BF32E3: TRExFit::PrepareMixedDataset(TRExFit::WorkspaceType) (TRExFit.cc:10421)
==41472==    by 0x4BF5DED: TRExFit::GetSignificance() (TRExFit.cc:5501) 
==41472==    by 0x116431: FitExample(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (trex-fitter.cc:506)
==41472==    by 0x10FE1E: main (trex-fitter.cc:696)

ROOT version

ROOT Version: 6.35.01
Built for linuxx8664gcc on Apr 08 2025, 06:57:24
From heads/master@7f390ce5ef

Installation method

build from source

Operating system

Ubuntu 24.10

Additional context

No response

[TomasDado]

I should have mentioned that I used the provided ROOT suppressions:

valgrind --leak-check=full          --show-leak-kinds=all          --track-origins=yes          --verbose          --log-file=valgrind-out.txt --suppressions=$ROOTSYS/etc/valgrind-root.supp

[ferdymercury]

Thanks for the report! Could you try to compile with #18327 and see if that solves the issue?

[TomasDado]

Thanks for the report! Could you try to compile with #18327 and see if that solves the issue?

Thanks for the quick fix! Indeed, with the changes I do not see any memory leaks from valgrind from this part of the code.

I still do see some leaks from things like:

TUnixSystem::UnixOpendir(char const*) (TUnixSystem.cxx:3996)

Not sure if I should open another issue for that?

But the current issue seems to be fixed with the changes, thanks!

[ferdymercury]

Not sure if I should open another issue for that?

Yes, please, open a separate one :)