[Help-glpk] Re: GLPK memory leak?

[Robbie Morrison]

> ------------------------------------------------------------
> To:          Adriana Kovashka <address@hidden>
> Subject:     [Help-glpk] Re: GLPK memory leak?
> Message-ID: <address@hidden>
> From:        Andrew Makhorin <address@hidden>
> Date:        Tue, 26 Oct 2010 20:00:51 +0400
> ------------------------------------------------------------
>
>> I'm using the GLPKMEX interface to GLPK for Matlab,
>> and I think I've isolated GLPK as the cause for my
>> program to slowly use more and more memory, leading
>> me to believe that there's a memory leak issue going
>> on. I checked the code for GLPKMEX since it's only
>> one file, and it appears that all memory that is
>> allocated is also freed. However, GLPK has lots of
>> functions, and I don't want to go through all of
>> them and check for leaks.
>>
>> Are you aware of any memory leaks in GLPK? In my
>> case, I'm running it on 64-bit Unix, and each
>> individual problem that is solved is very small
>> (takes 1 second or so) but I run lots and lots of
>> problems of this kind, so a typical run is about 5-6
>> hours.
>>
>> Any tips you have on how to avoid or fix this issue
>> would be appreciated. Thank you!

> I don't think this is glpk fault. You can check
> utilization of the memory used by glpk routines with
> the routine glp_mem_usage (for details please see the
> reference manual); it allows to see how much memory is
> currently allocated by glpk. If all glpk program
> objects have been deleted, only a small (about 200
> bytes) memory block remains allocated; to free it you
> can use the routine glp_free_env, which guarantees
> deallocating all the memory used by glpk. It seems to
> me that you should search for the memory leak in
> glpkmex or in your application.

Hello Adriana

I concur with Andrew.  I have never seen memory leak
from GLPK since version 4.25 (19-Dec-2007) when I
started working with the API.  Both on 32-bit and
64-bit Linux.  Every new build of my application is
tested with 'valgrind' on a small run and occasionally
I check a full sized simulation.  Like you, I also make
lots of little GLPK problems.  Ideally, one should mop up
with 'glp_free_env' on termination as Andrew suggests,
but that's not your problem.

It seems to me it would be hard to leak memory directly
from Matlab by poor scripting.  Have you tried running
Matlab and your model from within a memory checker?
Otherwise you contact The MathWorks.

As an aside, I thoroughly recommend
'std::[tr1::]shared_ptr' smart pointers from Boost,
when programming in C++.

Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from Webmail client]