Re: [SOSlib-discuss] memory exhaustion creating odeModels

[Eric F. <efe...@ph...>]

> Hi Eric,
> 
> Using examples/MAPK.xml I can get up to 40000 models (on 2GB RAM), but

> then I also get a segfault with your example program, while reading 
> the SBML model alone is Ok.
> 
> So odeModel seems to be comparatively big! We should profile that and 
> maybe try to optimize. Second, we should find out why it segfaults and

> doesn't just return NULLs and issue proper "out of memory" messages.

Hi Rainer,

The segfault is probably caused because I tested this on AIX, and memory
exhaustion checks were partially disabled on that platform. This is
caused by the fact the static memoryExhaustion variable is not correcly
initialised on AIX/gcc. This problem with static variables on AIX can be
found around on the net and nobody came up with a clear explanation
(although it is surprising such an important bug has not been
corrected). I'll contact people on gcc-users ML, but to be honest there
are no many AIX users there.
I should test it on Linux to check the memory exhaustion detection. 

> 
> It is important to note, that there is no leak in sosLib directly :) -

> and maybe also the big size is due to libSBML errors - not in parsing 
> from file but in creating a model, as outlined in the following:
> 
> Unfortunately, I can confirm real memory leaks (i.e. 
> increasing memory usage even when freeing each created odeModel 
> immediately), for which however libSBML seems to be responsible. I 
> tested version 3.1.1 so far, and memtest reports several leaks like 
> the one reported below, pointing to problems in ASTNode creation and 
> copying.

I used latest libSBML 3.3.0.

> 
> Maybe we can at least get rid of the internal simplified
> odeModel->simple which only consists of rate rules. Much work though.
> 
> One additional thought: maybe we should try to have one working 
> version of libSBML's ASTNode directly included in our source-code, so 
> we don't depend on libSBML versions which in many releases caused 
> (minor leak) problems.
> 
> 
> And finally some better news: No leaks and low memory footprint for 
> integratorInstance (incl. integration), and I can easily create 100000

> MAPK.xml integrators, after 30000 creations (without freeing of 
> course), memory is still only at 12% of my 2GB RAM.

Indeed, and this may be the best way to keep multiple instances of a
model.

> 
> I have copied my extended test file, derived from Eric's at 
> http://www.tbi.univie.ac.at/~raim/odeSolver/bugs/memleaks/
> 
> Please use something like:
> gcc -Wall memleak.c -o memleak -L/usr/local/lib -lODES -lsbml 
> -lsundials_kinsol -lsundials_cvodes -lsundials_nvecserial -ldl to 
> compile.
> 
> I used:
> valgrind --tool=memcheck --leak-check=yes --leak-check=full 
> --show-reachable=yes ./memleak to test for memory leaks.
> 
> Summary:
> 1) profile and optimize memory footprint of odeModel
> 2) avoid seg. fault when out of memory
> 3) check different libSBML versions
> 4a) get internal version of all ASTNode functionality and/or
> 4b) get rid of internal SBML with rate rules, directly construct 
> odeModel
> 
> Solution:
> Don't create thousands of odeModels (as odeModel_t is a constant and 
> completely unchangeable structure anyways!!), create thousands of 
> integratorInstances instead :) and set values there.
> 
> Rainer

Many thanks Rainer, I'll try to test this. I hope I can compile valgrind
on AIX :)

Kind regards,
Eric