COIN-OR::LEMON - Graph Library

Opened 9 years ago

Closed 9 years ago

#213 closed defect (fixed)

Memory leak in glpk.cc

Reported by: alpar Owned by: deba
Priority: major Milestone: LEMON 1.1 release
Component: core Version: hg main
Keywords: Cc: ladanyi, deba
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 deba 9 years ago.
ba124394367a.patch (1.9 KB) - added by deba 9 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: Changed 9 years ago by ladanyi

  • Cc 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 9 years ago by alpar

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 9 years ago by deba

Changed 9 years ago by deba

comment:3 follow-up: Changed 9 years ago by deba

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 ; follow-ups: Changed 9 years ago by alpar

  • Cc deba 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 9 years ago by alpar

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 9 years ago by alpar

Replying to alpar:

Replying to deba:

[ba124394367a] does not compile with gcc-3.3.

This issue is targeted by #236.

comment:7 Changed 9 years ago by alpar

  • Resolution set to fixed
  • Status changed from new to closed

The changes here are in the main now.

Note: See TracTickets for help on using tickets.