[Clp] potential memory leak in CLP with CBC trunk

Kish Shen kisshen at cisco.com
Tue Feb 10 00:32:42 EST 2009


Hi,

As part of testing the change in our interface code from using CbcModel 
to using CbcSolver, I ran our code with various tests using valgrind to 
check for memory usage problems. I noticed a potential problem when 
solving linear problems, using OsiClpSolverInterface to Clp (I am using 
the OSI/CLP that is downloaded with Cbc. I am testing with the trunk 
branch of Cbc, downloaded in Nov 2008). I wonder if this could be one of 
the memory leak fixes that John mentioned:

In the call to OsiClpSolver's initialSolve(), for a simple linear 
problem (2 contraints, 3 variables), there seem to be 2 memory 
allocation (via new, I assume) that are not freed. This is shown by the 
valgrind logs:

==4908== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==4908== malloc/free: in use at exit: 6,912 bytes in 3 blocks.
==4908== malloc/free: 1,291 allocs, 1,288 frees, 2,544,061 bytes allocated.
==4908== For counts of detected errors, rerun with: -v
==4908== searching for pointers to 3 not-freed blocks.
==4908== checked 124,440 bytes.
==4908==
==4908== 6,912 bytes in 3 blocks are still reachable in loss record 1 of 1
...

when the call to initialSolve() is commented out and recompiled, the 
valgrind trace has 2 less memory alloc:

==5076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==5076== malloc/free: in use at exit: 1,280 bytes in 1 blocks.
==5076== malloc/free: 747 allocs, 746 frees, 328,240 bytes allocated.
==5076== For counts of detected errors, rerun with: -v
==5076== searching for pointers to 1 not-freed blocks.
==5076== checked 123,920 bytes.
==5076==
==5076== 1,280 bytes in 1 blocks are still reachable in loss record 1 of 1
...

(the extra not-free block is probably unrelated to Clp). The only 
difference between the two runs is that the call to initialSolve() was 
commented out in the second run, so it seems that the two alloc must be 
done inside initialSolve(). Should these allocs be freed/deleted?

Is this expected to be a known problem that have been fixed, and if so, 
is the fix already in the latest trunk branch of Cbc? I have just tried 
to compile the latest trunk branch, but I was unsuccessful on the Linux 
box I am using, which has gcc 3.3.5. I have not yet looked into this in 
detail, but I suspect it may need a more recent version of gcc (I was 
able to compile the Cbc I downloaded in Nov 2008 with this gcc).

Thanks and 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.




More information about the Clp mailing list