Hi, Tim<br><br>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 <a href="http://www.codeproject.com/tools/visualleakdetector.asp">
http://www.codeproject.com/tools/visualleakdetector.asp</a>). Somehow it reports a leak caused by new Constant_double(d). It also reports leaks in mp_expression.cpp,<br><br>-------------------------------------<br>MP_expression sum(const MP_domain& d, const MP_expression& e) {
<br> return new Expression_sum(d, e); <br> }<br>-------------------------------------<br><br>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.
<br><br>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. <br><br>Cheers<br>Paul<br><br><br><div><span class="gmail_quote">On 5/24/07,
<b class="gmail_sendername">Tim Hultberg</b> <<a href="mailto:Tim.Hultberg@eumetsat.int">Tim.Hultberg@eumetsat.int</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Paul,<br> thanks for looking into this.<br><br>I agree that your first example is technically a memory leak, but<br>default_model is a static member of MP_model so the new is only called<br>once at start up when static objects are initialized. In other words the
<br>leak would not increase by calling getDefaultModel() a million times. I<br>could probably get rid of this leak by using a singleton, but I dont<br>consider this particular type of leak as a real problem.<br><br>The new Constant_double(d) is passed to the reference counting Handle
<br>class, which will delete it when there are no more references to it. So<br>if the handle class still works properly this should not cause a leak.<br><br>I used to trace memory leaks with the valgrind tool, but since the
<br>update to the autoconf/automake tools I have had problems compiling the<br>examples with debug version of flopc++. Hopefully Michael Kaut's example<br>Makefile suggestion will solve this problem and eventually I'll get some
<br>time to look into this again.<br><br>Cheers, Tim<br><br><br><br>Tim Hultberg<br><br><br>>>> "Paul Huang" <<a href="mailto:huangpaul99@gmail.com">huangpaul99@gmail.com</a>> 22/05/2007 19:53 >>>
<br>Hi, Tim<br><br>Thanks for fixing the leak. I spent sometime to look at the kinds of<br>mem<br>leaks Flopc++ has, and it seems that not all leaks are caused by<br>MP_domain.hpp. Many can be traced to pointers returned by a method
<br>call, and<br>the caller never deletes these pointers afterward. For instance, in<br>"mp_model.cpp", call getDefaultModel() returns a pointer to<br>MP_model(0), but<br>it is never deleted.<br>-------------------------
<br>MP_model& MP_model::default_model = *new MP_model(0);<br>MP_model* MP_model::current_model = &MP_model::default_model;<br>MP_model &MP_model::getDefaultModel() { return default_model;}<br>MP_model *MP_model::getCurrentModel() { return current_model;}
<br>-----------------------<br><br>Similar patterns can be found in other places. In "mp_constant.cpp",<br>---------------------------<br> Constant::Constant(double d) :<br> Handle<Constant_base*>(new Constant_double(d)) {}
<br>--------------------------<br>Constant(d) returns a pointer to Constant_double(d), and it is never<br>deleted<br>by its caller.<br><br>I guess it may require a major overhaul to fix all these leaks as there<br>are<br>
many methods return pointers to some newed classes.<br><br>Cheers<br>Paul<br><br><br><br><br><br><br>On 5/20/07, Tim Hultberg <<a href="mailto:Tim.Hultberg@eumetsat.int">Tim.Hultberg@eumetsat.int</a>> wrote:<br>>
<br>> Hi, Paul<br>><br>> yes this one is just as easy as you say. I have fixed it now in<br>> stable/1.0.<br>><br>> [if you find more easy ones, let me know :-)]<br>><br>> The remaining leaks (I am aware of) comes from some limitations in
<br>the<br>> current implementation of MP_domain. I have a leak free<br>implementation<br>> of it in branches/experiment/experiment/New_domain.hpp but I have<br>never<br>> had the time to integrate it properly.<br>
><br>> Cheers, Tim<br>><br>> Tim Hultberg<br>><br>> >>> "Paul Huang" <<a href="mailto:huangpaul99@gmail.com">huangpaul99@gmail.com</a>> 05/18/07 9:33 PM >>><br>> Hi, Tim
<br>><br>> I understand you know FlopC++ has quite a few memory leaks. Some<br>are<br>> minor<br>> but some are significant. After checking the source code, I assume,<br>> based on<br>> my limited understanding, some leaks are easy to fix. For example,
<br>in<br>> mp_model.cpp, a pointer c is newed and passed to<br>"Solver->loadProblem"<br>> but<br>> never released. Here is the code<br>><br>> ---------------------------------------------------
<br>> c = new double[n];<br>> for (int j=0; j<n; j++) {<br>> c[j] = 0.0;<br>> }<br>> for (size_t i=0; i<coefs.size(); i++) {<br>> int col = coefs[i].col;<br>> double elm = coefs[i].val;
<br>> c[col] = elm;<br>> }<br>><br>> // Column bounds<br>> for (int j=0; j<n; j++) {<br>> l[j] = 0.0;<br>> u[j] = inf;<br>> }<br>><br>> for (varIt i=Variables.begin(); i!=
Variables.end(); i++) {<br>> for (int k=0; k<(*i)->size(); k++) {<br>> l[(*i)->offset+k] = (*i)->lowerLimit.v[k];<br>> u[(*i)->offset+k] = (*i)->upperLimit.v[k];<br>> }<br>
> }<br>><br>> Solver->loadProblem(n, m, Cst, Rnr, Elm, l, u, c, bl, bu);<br>> -----------------------------------------------<br>><br>> My question is, is it just as easy as add "delete [] c" after
<br>calling<br>> "Solver->loadProblem" and then the problem will be fixed, or it is<br>not<br>> as<br>> easy as it looks and more complication is involved? If the former is<br>> true,<br>> then my second question is, when are you going to fix those
<br>easy-to-fix<br>> leaks? :-)<br>><br>><br>> Cheers<br>> Paul<br>><br>><br></blockquote></div><br>