[FlopCpp] memory leaks

[Paul Huang]

Hi, Tim

You are right. The second example should not cause a leak. I am using VC++
2005 with a memory leak detector called VLD (It is good, and in case you
want to give it a try, here is the link
http://www.codeproject.com/tools/visualleakdetector.asp). Somehow it reports
a leak caused by new Constant_double(d). It also reports leaks in
mp_expression.cpp,

-------------------------------------
MP_expression sum(const MP_domain& d, const MP_expression& e) {
    return new Expression_sum(d, e);
  }
-------------------------------------

Would the above code cause a leak? As it returns a pointer to a
Expression_sum(d, e). Other operators (+,-,* /) in the same file also return
pointers.

I have the same problem with Valgrind, it can only report a summary of total
memory leaks, but somehow can not point to where these leaks happen.

Cheers
Paul


On 5/24/07, Tim Hultberg <Tim.Hultberg at eumetsat.int> wrote:
>
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/flopcpp/attachments/20070524/84e5c778/attachment.html