[FlopCpp] memory leaks

[Tim Hultberg]

Hi Paul,
  thanks for looking into this.

I agree that your first example is technically a memory leak, but default_model is a static member of MP_model so the new is only called once at start up when static objects are initialized. In other words the leak would not increase by calling getDefaultModel() a million times. I could probably get rid of this leak by using a singleton, but I dont consider this particular type of leak as a real problem.

The new Constant_double(d) is passed to the reference counting Handle class, which will delete it when there are no more references to it. So if the handle class still works properly this should not cause a leak.

I used to trace memory leaks with the valgrind tool, but since the update to the autoconf/automake tools I have had problems compiling the examples with debug version of flopc++. Hopefully Michael Kaut's example Makefile suggestion will solve this problem and eventually I'll get some time to look into this again.

Cheers, Tim



Tim Hultberg


>>> "Paul Huang" <huangpaul99 at gmail.com> 22/05/2007 19:53 >>>
Hi, Tim

Thanks for fixing the leak. I spent sometime to look at the kinds of mem
leaks Flopc++ has, and it seems that not all leaks are caused by
MP_domain.hpp. Many can be traced to pointers returned by a method call, and
the caller never deletes these pointers afterward. For instance, in
"mp_model.cpp", call getDefaultModel() returns a pointer to MP_model(0), but
it is never deleted.
-------------------------
MP_model& MP_model::default_model = *new MP_model(0);
MP_model* MP_model::current_model = &MP_model::default_model;
MP_model &MP_model::getDefaultModel() { return default_model;}
MP_model *MP_model::getCurrentModel() { return current_model;}
-----------------------

Similar patterns can be found in other places. In "mp_constant.cpp",
---------------------------
 Constant::Constant(double d) :
    Handle<Constant_base*>(new Constant_double(d)) {}
--------------------------
Constant(d) returns a pointer to Constant_double(d), and it is never deleted
by its caller.

I guess it may require a major overhaul to fix all these leaks as there are
many methods return pointers to some newed classes.

Cheers
Paul






On 5/20/07, Tim Hultberg <Tim.Hultberg at eumetsat.int> wrote:
>
> Hi, Paul
>
> yes this one is just as easy as you say. I have fixed it now in
> stable/1.0.
>
> [if you find more easy ones, let me know :-)]
>
> The remaining leaks (I am aware of) comes from some limitations in the
> current implementation of MP_domain. I have a leak free implementation
> of it in branches/experiment/experiment/New_domain.hpp but I have never
> had the time to integrate it properly.
>
> Cheers, Tim
>
> Tim Hultberg
>
> >>> "Paul Huang" <huangpaul99 at gmail.com> 05/18/07 9:33 PM >>>
> Hi, Tim
>
> I understand you know FlopC++ has quite a few memory leaks.  Some are
> minor
> but some are significant. After checking the source code, I assume,
> based on
> my limited understanding, some leaks are easy to fix. For example, in
> mp_model.cpp, a pointer c is newed and passed to "Solver->loadProblem"
> but
> never released. Here is the code
>
> ---------------------------------------------------
> c =  new double[n];
>   for (int j=0; j<n; j++) {
>     c[j] = 0.0;
>   }
>   for (size_t i=0; i<coefs.size(); i++) {
>     int col = coefs[i].col;
>     double elm = coefs[i].val;
>     c[col] = elm;
>   }
>
>   // Column bounds
>   for (int j=0; j<n; j++) {
>     l[j] = 0.0;
>     u[j] = inf;
>   }
>
>   for (varIt i=Variables.begin(); i!=Variables.end(); i++) {
>     for (int k=0; k<(*i)->size(); k++) {
>       l[(*i)->offset+k] = (*i)->lowerLimit.v[k];
>       u[(*i)->offset+k] = (*i)->upperLimit.v[k];
>     }
>   }
>
>   Solver->loadProblem(n, m, Cst, Rnr, Elm, l, u, c, bl, bu);
> -----------------------------------------------
>
> My question is,  is it just as easy as add "delete [] c" after calling
> "Solver->loadProblem" and then the problem will be fixed, or it is not
> as
> easy as it looks and more complication is involved? If the former is
> true,
> then my second question is, when are you going to fix those easy-to-fix
> leaks? :-)
>
>
> Cheers
> Paul
>
>