[Clp] potential memory leak in CLP with CBC trunk

[Kish Shen]

Stefan Vigerske wrote:
> Hi,
> 
> valgrind should also tell you where the memory has been allocated that
> has not been freed. Such an info would be very helpful, I think :-).
> You would need to specify --leak-check=full --show-reachable=yes as
> valgrind options.
> Most info you get when the code is compiled in debug-mode.

Hi Stefan,

Yes, I have been running valgrind with leak-check=full and 
show-reachable=yes, but the result from this is difficult to understand, 
and I strongly suspect that valgrind is not correctly finding the still 
reachable culprits, or perhaps even determining still reachable correctly:

My use of valgrind is mainly trying to see if my own code is leaking 
memory, and I have found various cases that are difficult to understand, 
but seem to suggest that the problem is not in my own code. This one 
with initialSolve() is one, another is with CoinMessahgeHandler -- in 
that case, I was able to simplify the code to simply allocating a 
CoinMessageHandler with new, and then immediately deleting it -- this 
was all I did in that program, and yet I still got 640 bytes reachable 
[I posted about this earlier in the Coin-discuss mailing list].

What I mean about the results being difficult to understand is that in 
these tests, the location of the supposedly reachable blocks keep 
changing. In many cases, valgrind reports the culprit in procedures that 
I know was not called in that execution, and when I comment out that 
procedure, it simply show some other location as the culprit. In some 
other cases, where the culprit is reported in code that is executed, 
commenting out the allocation (the new, and of course the corresponding 
delete), simply resulted in the report of another culprit, often with a 
different size (but the same number of reachable blocks, even though the 
only change should just mean one less new and delete).

For what it is worth, in the current initialSolve() example, in both 
cases, only one stack trace is shown by the show-reachable, and it is 
claiming that the culprit is the

     lp->Solver = new OsiXxxSolverInterface();

line, even though Solver is deleted in both cases. I have ran the code 
with gdb, and checked that the new and delete are applied to the same 
Solver (i.e. it has the same address with p/x Solver).

Cheers,

Kish



-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.