COIN-OR::LEMON - Graph Library

Opened 16 years ago

Closed 16 years ago

#213 closed defect (fixed)

Memory leak in glpk.cc

Reported by: Alpar Juttner Owned by: Balazs Dezso
Priority: major Milestone: LEMON 1.1 release
Component: core Version: hg main
Keywords: Cc: Akos Ladanyi, Balazs Dezso
Revision id: 861a9d5ff283

Description

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.
$

Attachments (2)

0fec6a017ead.patch (1.7 KB) - added by Balazs Dezso 16 years ago.
ba124394367a.patch (1.9 KB) - added by Balazs Dezso 16 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 16 years ago by Akos Ladanyi

Cc: Akos Ladanyi added

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;
}

comment:2 in reply to:  1 Changed 16 years ago by 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++.

Changed 16 years ago by Balazs Dezso

Attachment: 0fec6a017ead.patch added

Changed 16 years ago by Balazs Dezso

Attachment: ba124394367a.patch added

comment:3 Changed 16 years ago by 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?

comment:4 in reply to:  3 ; Changed 16 years ago by Alpar Juttner

Cc: Balazs Dezso added

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

comment:5 in reply to:  4 Changed 16 years ago by 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.

comment:6 in reply to:  4 Changed 16 years ago by Alpar Juttner

Replying to alpar:

Replying to deba:

[ba124394367a] does not compile with gcc-3.3.

This issue is targeted by #236.

comment:7 Changed 16 years ago by Alpar Juttner

Resolution: fixed
Status: newclosed

The changes here are in the main now.

Note: See TracTickets for help on using tickets.