Bug #42: Possible memory leak in MiceModule class - MAUS - MICEmine

Bug #42

Possible memory leak in MiceModule class

Added by Karadzhov, Yordan about 13 years ago. Updated about 12 years ago.

Status:

Closed

Priority:

Urgent

Assignee:

Rogers, Chris

Category:

common_py

Target version:

MAUS-v0.0.9

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.

Updated by Rogers, Chris about 13 years ago

Assignee set to Rogers, Chris

Updated by Rogers, Chris about 13 years ago

Category set to Config

Updated by Rogers, Chris about 13 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.

Updated by Rogers, Chris over 12 years ago

Project changed from G4MICE to MAUS
Category deleted (~~Config~~)

Updated by Rogers, Chris over 12 years ago

Priority changed from Normal to High

Updated by Tunnell, Christopher over 12 years ago

Coverity caught some leaks in MiceModule and TofRec...

Updated by Rogers, Chris over 12 years ago

Category set to common_py
Target version set to Future MAUS release

Updated by Rogers, Chris about 12 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...