Bug #1467

Feature #1290: === Core: framework ===

Remove memory leakages from functional test machinery

Added by pospelov almost 4 years ago. Updated over 3 years ago.

Status:ResolvedStart date:16 Jun 2016
Priority:NormalDue date:
Assignee:wuttke% Done:

0%

Category:-
Target version:-

Description

  • Leakages have been present already in previous version of functional test. There are probably some new.
  • All builders with components should delete them on destruction
  • FutestSuite should delete test on exit

168 bytes in 1 blocks are possibly lost in loss record 375 of 751
  in TestFormFactorsRegistry::TestFormFactorsRegistry() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/SubtestRegistry.cpp:98
  1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
  2: TestFormFactorsRegistry::TestFormFactorsRegistry() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/SubtestRegistry.cpp:98
  3: FutestSuite::execute_subtests() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:67
  4: FutestSuite::execute(int, char**) in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:44
  5: main in /home/pospelov/development/BornAgain/BornAgain/Tests/Functional/Core/CoreSuite.cpp:30

176 (96 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 407 of 751
  in FormFactorFullSphere::clone() const in /home/pospelov/development/BornAgain/BornAgain/Core/FormFactors/FormFactorFullSphere.cpp:36
  1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
  2: FormFactorFullSphere::clone() const in /home/pospelov/development/BornAgain/BornAgain/Core/FormFactors/FormFactorFullSphere.cpp:36
  3: ISampleBuilder::getFormFactor() const in /home/pospelov/development/BornAgain/build-debug/lib/_libBornAgainCore.so
  4: ParticleInTheAirBuilder::buildSample() const in /home/pospelov/development/BornAgain/BornAgain/Core/StandardSamples/ParticleInTheAirBuilder.cpp:34
  5: Simulation::updateSample() in /home/pospelov/development/BornAgain/BornAgain/Core/Algorithms/Simulation.cpp:163
  6: Simulation::runSingleSimulation() in /home/pospelov/development/BornAgain/BornAgain/Core/Algorithms/Simulation.cpp:179
  7: Simulation::runSimulation() in /home/pospelov/development/BornAgain/BornAgain/Core/Algorithms/Simulation.cpp:83
  8: CoreFutest::runTest() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/CoreFutest.cpp:46
  9: FutestSuite::execute_subtests() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:85
  10: FutestSuite::execute(int, char**) in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:44
  11: main in /home/pospelov/development/BornAgain/BornAgain/Tests/Functional/Core/CoreSuite.cpp:30

1,389 (336 direct, 1,053 indirect) bytes in 21 blocks are definitely lost in loss record 463 of 751
  in OutputDataReadFactory::getReader(std::string const&) in /home/pospelov/development/BornAgain/BornAgain/Core/InputOutput/OutputDataReadFactory.cpp:26
  1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
  2: OutputDataReadFactory::getReader(std::string const&) in /home/pospelov/development/BornAgain/BornAgain/Core/InputOutput/OutputDataReadFactory.cpp:26
  3: IntensityDataIOFactory::readOutputData(std::string const&) in /home/pospelov/development/BornAgain/BornAgain/Core/InputOutput/IntensityDataIOFactory.cpp:26
  4: CoreFutest::runTest() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/CoreFutest.cpp:51
  5: FutestSuite::execute_subtests() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:85
  6: FutestSuite::execute(int, char**) in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:44
  7: main in /home/pospelov/development/BornAgain/BornAgain/Tests/Functional/Core/CoreSuite.cpp:30

4,929,265 (1,512 direct, 4,927,753 indirect) bytes in 21 blocks are definitely lost in loss record 751 of 751
  in FutestSuite::execute_subtests() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:82
  1: operator new(unsigned long) in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
  2: CoreSuite::getFutest() const in /home/pospelov/development/BornAgain/build-debug/bin/CoreSuite
  3: FutestSuite::execute_subtests() in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:82
  4: FutestSuite::execute(int, char**) in /home/pospelov/development/BornAgain/BornAgain/Core/TestMachinery/FutestSuite.cpp:44
  5: main in /home/pospelov/development/BornAgain/BornAgain/Tests/Functional/Core/CoreSuite.cpp:30

History

#1 Updated by wuttke almost 4 years ago

  • Priority changed from Normal to Low
  • Parent task set to #1290

#2 Updated by pospelov almost 4 years ago

Here are some additional explanations about release procedure.

Before every release we check BornAgain for leakages. This is done twice: using "Instrument" tool on MacOS and Valgrind on Linux.
  • MacOS Instrument is handy, doesn't require debug compilation, fast, but often misses the leakages.
  • Valgrind catches everything, but works quite long.
On Linux, Valgrind can be used in two ways
  • From command line (requires knowledge of magic command line parameters, produces huge file which is difficult to understand).
  • From Qt creator (very convenient and natural navigation over valgrind errors, allows to jump straight to the line of code there the leak is).
So, the simplest way to find leakages in Core is following.
  • In Qt creator, open executable, which uses as many as possible of our functionality.
  • Run "Analyze", fix errors.
    • Before, as such executable, we were using App and it's TestPerformance part.
    • Now, with the elimination of App, the next natural candidate is CoreSuite/FormFactors.

For the moment, CoreSuite/FormFactors leaks. There are a lot of warnings and one have to be able to disentangle leakages in functional test machinery, and in the library itself.

The easiest would be to eliminate leakages. So I would prefer to have the whole Issue moving in the direction of "zero tolerance to leakages".

#3 Updated by wuttke almost 4 years ago

Two causes of leaks fixed in ffa5fab.
The remaining two (in SubtestRegistry and OutputDataReadFactory) are probably best handled by a somewhat deeper refactoring.

#4 Updated by herck almost 4 years ago

  • Description updated (diff)

#5 Updated by wuttke over 3 years ago

  • Status changed from Backlog to Sprint
  • Assignee set to wuttke
  • Priority changed from Low to Normal

#6 Updated by wuttke over 3 years ago

Memory leak in I/O machinery confirmed, located, and fixed in 4765dcd.

#7 Updated by wuttke over 3 years ago

  • Status changed from Sprint to Resolved

Also available in: Atom PDF