how to avoid leaks?

[Ralf Grosse-Kunstleve]

I'm experimenting with the SimTK 1.0 Linux Release binary and SimTKExamples1.0c.zip posted yesterday.

My interest is implementation of torsion angle dynamics in a crystallographic refinement program. Therefore I'm concentrating on ExampleSimpleProtein.cpp and the new adenylate_mobilities.1.0.cpp.

To get a quick idea of the code health, I'm checking for memory access problems and leaks.
In ExampleSimpleProtein.cpp I commented out the VTKEventReporter and shortened the simulation time to 2 seconds. I used valgrind (valgrind.org) to check for memory access problems. I'm happy to report that valgrind doesn't find any errors, which is very encouraging.

To check for memory leaks, I changed main() to work() and added a new main() calling work() in an endless loop. The complete code is below. While running the newly compiled executable, I'm checking the memory allocation of the process with the "top" command. It shows that the memory allocation is increasing steadily, suggesting that some objects instantiated in work() aren't destroyed properly. Do I need to add explicit cleanup code?

Thanks!
Ralf

P.S.: I'm using Fedora 8, which comes with gcc 4.1.2.


Modified ExampleSimpleProtein.cpp:

#include "SimTKmolmodel.h"
//#include "SimTKsimbody_aux.h" // for vtk visualization

using namespace SimTK;
using namespace std;

void
work()
{
CompoundSystem system; // molecule-specialized simbody System
SimbodyMatterSubsystem matter(system); // matter is required
TinkerDuMMForceFieldSubsystem dumm(system); // molecular force field
DecorationSubsystem artwork(system); // for drawing vtk visualization

dumm.loadAmber99Parameters();

Protein protein("SIMTK");
protein.assignBiotypes();
system.adoptCompound(protein);

system.updDefaultSubsystem();//.addEventReporter(new VTKEventReporter(system, 0.020));

system.modelCompounds(); // finalize multibody system

State state = system.realizeTopology();

// Simulate it.

VerletIntegrator integ(system);
TimeStepper ts(system, integ);
ts.initialize(state);
ts.stepTo(2.0);
}

[Ralf Grosse-Kunstleve]

Sorry, a bit of code at the end was missing:

int main()
{
while (true) {
std::cout << "WORK" << std::endl;
work();
}
return 0;
}

[Christopher Bruns]

Hi Ralf-

I am unsure where the memory leak might be. I am surprised to hear that valgrind does not see any problem. This might make it more difficult to pinpoint the memory allocation issue. I will try to look into this further.

My current understanding is that even if you include the "new VTKEventReporter..." code, the VTKEventReporter will be cleaned up by the system when it is deallocated.

It is possible that the source of the memory problem has already been fixed in our development code base. We will be releasing version 1.5 in August, I believe.

-Chris Bruns

[Peter Eastman]

Hi Ralf,

We run all our test cases through Valgrind, so hopefully that catches most of the memory leaks. We have had problems with leaks in VTK, so don't be surprised if you encounter those, but I see you've removed the visualization in this example, so that shouldn't be the problem here. If you set it to only run a finite number of times and then put it through Valgrind, does it report anything?

Anyway, I'll try running your example in the most recent development version of SimTK and see if I can detect any problems.

Peter

[Ralf Grosse-Kunstleve]

Hi Peter,

> If you set it to only run a finite number of times
> and then put it through Valgrind, does it report
> anything?

Yes:

http://cci.lbl.gov/~rwgk/tmp/simtk/Exam ... lgrind_log

For completeness, the corresponding source code is here:

http://cci.lbl.gov/~rwgk/tmp/simtk/Exam ... 07_16_1509

The valgrind log is probably not all that useful because I
only have the Release build.

Ralf

[Peter Eastman]

Actually, that was very useful. It's a known memory leak in the GBSA implementation, which was fixed quite a while ago. So it will be gone in 1.5.

Peter