Project

General

Profile

Bug #42

Possible memory leak in MiceModule class

Added by Karadzhov, Yordan almost 11 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
common_py
Target version:
Start date:
24 September 2010
Due date:
% Done:

100%

Estimated time:
Workflow:

Description

I found that the memory usage of an application which calls TofRec::Process() increases with a steady rate. I isolated the leak to the constructor of the class TofSpacePoint where the position of the point is calculated by calling the functions MiceModule::dimensions() and MiceModule::globalPosition(). If I comment the lines where these functions are called the problem disappear and the memory used by the process is stable. However the problem in MiceModule::dimensions() and MiceModule::globalPosition() is not obvious and everything there looks OK.

#1

Updated by Rogers, Chris almost 11 years ago

  • Assignee set to Rogers, Chris
#2

Updated by Rogers, Chris almost 11 years ago

  • Category set to Config
#3

Updated by Rogers, Chris almost 11 years ago

Looks like a memory leak in CLHEP::Evaluator

Leaks memory each time I make an evalute call. I wonder if ROOT has an equivalent function. Otherwise we have to write our own.

#4

Updated by Rogers, Chris over 10 years ago

  • Project changed from G4MICE to MAUS
  • Category deleted (Config)
#5

Updated by Rogers, Chris over 10 years ago

  • Priority changed from Normal to High
#6

Updated by Tunnell, Christopher over 10 years ago

Coverity caught some leaks in MiceModule and TofRec...

#7

Updated by Rogers, Chris over 10 years ago

  • Category set to common_py
  • Target version set to Future MAUS release
#8

Updated by Rogers, Chris almost 10 years ago

  • Priority changed from High to Urgent

Note that this is still a problem I believe - and will crash us in the control room. Valgrind reports e.g.

==8182== 2 bytes in 1 blocks are definitely lost in loss record 1,215 of 33,820
==8182==    at 0x4C25DBC: operator new[](unsigned long) (vg_replace_malloc.c:305)
==8182==    by 0xA7F0DD4: HepTool::Evaluator::evaluate(char const*) (Evaluator.cc:620)
==8182==    by 0x1B456286: ModuleTextFileIO::parseString(std::string const&, double&) (ModuleTextFileIO.cc:300)
==8182==    by 0x1B456AA0: ModuleTextFileIO::parseString(std::string const&, CLHEP::Hep3Vector&) (ModuleTextFileIO.cc:343)
==8182==    by 0x1B444AC0: MiceModule::propertyHep3Vector(std::string) const (MiceModule.cc:535)
==8182==    by 0x1B43FC83: MiceModule::position() const (MiceModule.cc:204)
==8182==    by 0x1B43F7D9: MiceModule::relativeTransform(MiceModule const*) const (MiceModule.cc:181)
==8182==    by 0x1B44002E: MiceModule::relativeRotation(MiceModule const*) const (MiceModule.cc:239)
==8182==    by 0x1B4400C9: MiceModule::globalRotation() const (MiceModule.cc:254)
==8182==    by 0x1B47F87F: MAUS::VirtualPlaneManager::ConstructFromModule(MiceModule const*) (VirtualPlanes.cc:325)
==8182==    by 0x1B47EBAF: MAUS::VirtualPlaneManager::ConstructVirtualPlanes(BTField const*, MiceModule*) (VirtualPlanes.cc:270)
==8182==    by 0x4C424A: (anonymous namespace)::VirtualPlaneManagerTest_ConstructFromModule_OtherStuffTest_Test::TestBody() (VirtualPlaneTest.cc:357)

which seems to be some lurking memory leak in CLHEP. Solution is to workaround HepTool::Evaluator, e.g. use python eval() or root TFunction instead...

#9

Updated by Rogers, Chris almost 10 years ago

  • Status changed from Open to In Progress
  • % Done changed from 0 to 50
#11

Updated by Rogers, Chris almost 10 years ago

Replaced the CLHEP expression evaluator with python...

#12

Updated by Rogers, Chris almost 10 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

And merged with trunk

#13

Updated by Rogers, Chris almost 10 years ago

  • Target version changed from Future MAUS release to MAUS-v0.0.9

Also available in: Atom PDF