Memory leak in glpk.cc

[Alpar Juttner]

Valgrind reports (see below) memory leak in lp_test and mip_test when GLPK is enabled.

$ valgrind --leak-check=full --show-reachable=yes ./lp_test
==14636== Memcheck, a memory error detector.
==14636== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==14636== Using LibVEX rev 1854, a library for dynamic binary translation.
==14636== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==14636== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==14636== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==14636== For more details, rerun with: -v
==14636== 
==14636== 
==14636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==14636== malloc/free: in use at exit: 1,108 bytes in 1 blocks.
==14636== malloc/free: 3,096 allocs, 3,095 frees, 8,841,857 bytes allocated.
==14636== For counts of detected errors, rerun with: -v
==14636== searching for pointers to 1 not-freed blocks.
==14636== checked 116,024 bytes.
==14636== 
==14636== 1,108 bytes in 1 blocks are still reachable in loss record 1 of 1
==14636==    at 0x4027DDE: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==14636==    by 0x4094243: _glp_lib_init_env (in /usr/lib/libglpk.so.0.20.0)
==14636==    by 0x40943C4: _glp_lib_link_env (in /usr/lib/libglpk.so.0.20.0)
==14636==    by 0x409590B: _glp_lib_xmalloc (in /usr/lib/libglpk.so.0.20.0)
==14636==    by 0x405D3F2: glp_create_prob (in /usr/lib/libglpk.so.0.20.0)
==14636==    by 0x805ED5E: lemon::GlpkBase::GlpkBase() (glpk.cc:32)
==14636==    by 0x80605C7: lemon::GlpkLp::GlpkLp() (glpk.cc:528)
==14636==    by 0x805AE97: main (lp_test.cc:365)
==14636== 
==14636== LEAK SUMMARY:
==14636==    definitely lost: 0 bytes in 0 blocks.
==14636==      possibly lost: 0 bytes in 0 blocks.
==14636==    still reachable: 1,108 bytes in 1 blocks.
==14636==         suppressed: 0 bytes in 0 blocks.
$

[Akos Ladanyi]

I don't think this is a bug in LEMON since valgrind reports the same amount of 'still reachable' memory blocks in case of lp_test as in case of the next simple C program:

#include <glpk.h>

int main(int argc, char** argv)
{
    LPX *lp;
    lp = lpx_create_prob();
    lpx_delete_prob(lp);
    return 0;
}

[Alpar Juttner]

Replying to ladanyi:

I don't think this is a bug in LEMON since valgrind reports the same amount of 'still reachable' memory blocks in case of lp_test as in case of the next simple C program:

You are right. GLPK allocates a global structure which should be deallocated manually on exit. It causes no problem, but it makes it more difficult to spot the real memory leaks. Therefore we should

• at least use GLPK's cleanup function in the test files
• or (a bit better) provide a cleanup function in our GLPK interface
• or do this automatically in a destructor of a global class.

The last one would be the cleanest solution, but Balazs had some concerns if it works reliably in C++.

[Balazs Dezso]

I made the second and the third version.

On GCC both verion worked well, the third is also efficient, because the deallocation is done only, when at least one thing is called from the glpk.cc (glpk.o). So it seems, it works. Could you check the other platforms also?

[Alpar Juttner]

Replying to deba:

[ba124394367a] does not compile with gcc-3.3.

libtool: compile:  g++-3.3 -DHAVE_CONFIG_H -I.. -I. -g -O2 -MT lemon/lemon_libemon_la-lp_skeleton.lo -MD -MP -MF lemon/.deps/lemon_libemon_la-lp_skeleton.Tpo -c ../lemon/lp_skeleton.cc -o lemon/lemon_libemon_la-lp_skeleton.o
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1773: sorry, unimplemented: adjusting pointers for covariant 
   returns
make: *** [lemon/lemon_libemon_la-lp_base.lo] Error 1
make: *** Waiting for unfinished jobs....
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
../lemon/lp_base.h:1959: sorry, unimplemented: adjusting pointers for covariant 
   returns
In file included from ../lemon/lp_skeleton.cc:19:
../lemon/lp_skeleton.h:176: error: conflicting return type specified for `
   virtual lemon::LpSkeleton* lemon::LpSkeleton::_newSolver() const'
../lemon/lp_base.h:921: error:   overriding `virtual lemon::LpBase* 
   lemon::LpBase::_newSolver() const'
../lemon/lp_skeleton.h:178: error: conflicting return type specified for `
   virtual lemon::LpSkeleton* lemon::LpSkeleton::_cloneSolver() const'
../lemon/lp_base.h:922: error:   overriding `virtual lemon::LpBase* 
   lemon::LpBase::_cloneSolver() const'
../lemon/lp_skeleton.h:143: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:143: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:143: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:143: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:218: error: conflicting return type specified for `
   virtual lemon::MipSkeleton* lemon::MipSkeleton::_newSolver() const'
../lemon/lp_base.h:921: error:   overriding `virtual lemon::LpBase* 
   lemon::LpBase::_newSolver() const'
../lemon/lp_skeleton.h:221: error: conflicting return type specified for `
   virtual lemon::MipSkeleton* lemon::MipSkeleton::_cloneSolver() const'
../lemon/lp_base.h:922: error:   overriding `virtual lemon::LpBase* 
   lemon::LpBase::_cloneSolver() const'
../lemon/lp_skeleton.h:188: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:188: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:188: sorry, unimplemented: adjusting pointers for 
   covariant returns
../lemon/lp_skeleton.h:188: sorry, unimplemented: adjusting pointers for 
   covariant returns
make: *** [lemon/lemon_libemon_la-lp_skeleton.lo] Error 1

Compilation exited abnormally with code 2 at Wed Feb 25 16:32:21

[Alpar Juttner]

Replying to alpar:

Replying to deba:

[ba124394367a] does not compile with gcc-3.3.

On the other hand, it works well (with no memory leak) with gcc-4.1, gcc-4.3, intel C++ 11.0.

[Alpar Juttner]

Replying to alpar:

Replying to deba:

[ba124394367a] does not compile with gcc-3.3.

This issue is targeted by #236.

[Alpar Juttner]

The changes here are in the main now.