Skip to content

NewVrtSecInclusiveTool: Fix the memory leak/error in VrtSecMulti

Looking at the memory profile of some of the most recent derivation jobs, I noticed that we have a potential memory leak. Looking closer, I found the following:

5,422,920 (10,608 direct, 5,412,312 indirect) bytes in 78 blocks are definitely lost in loss record 69,477 of 69,480
  at 0x403473B: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:530)
  by 0xA0E9E27A: Rec::NewVrtSecInclusiveTool::getVrtSecMulti(Rec::workVectorArrxAOD*, xAOD::Vertex_v1 const&, boost::adjacency_list<boost::listS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>&) const (VrtSecMulti.cxx:459)
  by 0xA0E72DFB: Rec::NewVrtSecInclusiveTool::findAllVertices(std::vector<xAOD::TrackParticle_v1 const*, std::allocator<xAOD::TrackParticle_v1 const*> > const&, xAOD::Vertex_v1 const&) const (NewVrtSecInclusiveTool.cxx:344)
  by 0xA0E5D50B: Rec::NewVrtSecInclusiveAlg::execute(EventContext const&) const (NewVrtSecInclusiveAlg.cxx:75)
  by 0x2C1C1696: Gaudi::Algorithm::sysExecute(EventContext const&) (Algorithm.cpp:366)

This is about 5 MB over 100 events in the standard MC21a SPOT test, so it's sizable. Anyways, this MR should fix this leak but it goes a bit beyond that. To me it looks like this leak also uncovered a bug in the code in which tmpVertex being shadowed means we were not only leaking memory but also some of the time (when nth==1), we were missing a vertex. I'm not 100% sure how much of an effect this would have on the overall result but it's worth noting.

cc: @kostyuk (based on the code history), @jcatmore and @calpigia (for the DAOD production)

Merge request reports

Loading