[Help-glpk] Memory leak?

[Murilo Soares]

Andrew,
I was doing a memory check in a program that uses glpk 4.42 to solve 
several LP problems using valgrind tool (command: valgrind 
--leak-check=full --show-reachable=yes <program>). The functions I
 use to allocate and deallocate the LP problems are glp_create_prob() 
and glp_delete_prob(). After valgrind execution I got the following 
output:

==2637== 
==2637== HEAP SUMMARY:
==2637==     in use at exit: 1,108 bytes in 1 blocks
==2637==   total heap usage: 807,331 allocs, 807,330 frees, 949,169,684 
bytes allocated
==2637== 
==2637== 1,108 bytes in 1 blocks are still reachable in loss record 1 of
 1
==2637==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==2637==    by 0x805C823: _glp_lib_init_env (glplib01.c:67)
==2637==    by 0x805C994: _glp_lib_link_env (glplib01.c:132)
==2637==    by 0x805D600: _glp_lib_xmalloc (glplib07.c:60)
==2637==    by 0x80507B2: glp_create_prob (glpapi01.c:104)
==2637==    by 0x804C2DE: main (main.c:57)
==2637== 
==2637== LEAK SUMMARY:
==2637==    definitely lost: 0 bytes in 0 blocks
==2637==    indirectly lost: 0 bytes in 0 blocks
==2637==      possibly lost: 0 bytes in 0 blocks
==2637==    still reachable: 1,108 bytes in 1 blocks
==2637==         suppressed: 0 bytes in 0 blocks
==2637== 
==2637== For counts of detected and suppressed errors, rerun with: -v
==2637== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)

As it can be seen, there seems to remain 1.108bytes still reachable,
 maybe due to a missing free call. I guess that the environment block 
env (glplib01.c:67) has not been deallocated, that is, 
lib_free_env(void) may have not been called properly.

The example sample.c was also compiled and executed under valgrind 
and the same behavior was reported, as shown below:

address@hidden:/media/hd/Otimizacao/glpk-4.42/examples$ 
valgrind 
--leak-check=full --show-reachable=yes ./sample
==3611== Memcheck, a memory error detector
==3611== Copyright (C) 2002-2009, and GNU GPL #39;d, by Julian Seward et al.
==3611== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for 
copyright info
==3611== Command: ./sample
==3611== 
*     0: obj =   0.000000000e+00  infeas =  0.000e+00 (0)
*     2: obj =   7.333333333e+02  infeas =  0.000e+00 (0)
OPTIMAL SOLUTION FOUND

z = 733.333; x1 = 33.3333; x2 = 66.6667; x3 = 0
==3611== 
==3611== HEAP SUMMARY:
==3611==     in use at exit: 1,108 bytes in 1 blocks
==3611==   total heap usage: 80 allocs, 79 frees, 31,226 bytes allocated
==3611== 
==3611== 1,108 bytes in 1 blocks are still reachable in loss record 1 of
 1
==3611==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==3611==    by 0x407ADA3: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x407AF24: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x407C46B: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x40428C2: glp_create_prob (in 
/usr/lib/libglpk.so.0.23.0)
==3611==    by 0x8048804: main (in 
/media/hd/Otimizacao/glpk-4.42/examples/sample)
==3611== 
==3611== LEAK SUMMARY:
==3611==    definitely lost: 0 bytes in 0 blocks
==3611==    indirectly lost: 0 bytes in 0 blocks
==3611==      possibly lost: 0 bytes in 0 blocks
==3611==    still reachable: 1,108 bytes in 1 blocks
==3611==         suppressed: 0 bytes in 0 blocks
==3611== 
==3611== For counts of detected and suppressed errors, rerun with: -v
==3611== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 8)

Can
 I safely disregard this reported leak?
Thanks for your help.
Murilo




Andrew,
I was doing a memory check in a program that uses glpk 4.42 to solve 
several LP problems using valgrind tool (command: valgrind 
--leak-check=full --show-reachable=yes <program>). The functions I
 use to allocate and deallocate the LP problems are glp_create_prob() 
and glp_delete_prob(). After valgrind execution I got the following 
output:

==2637== 
==2637== HEAP SUMMARY:
==2637==     in use at exit: 1,108 bytes in 1 blocks
==2637==   total heap usage: 807,331 allocs, 807,330 frees, 949,169,684 
bytes allocated
==2637== 
==2637== 1,108 bytes in 1 blocks are still reachable in loss record 1 of
 1
==2637==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==2637==    by 0x805C823: _glp_lib_init_env (glplib01.c:67)
==2637==    by 0x805C994: _glp_lib_link_env (glplib01.c:132)
==2637==    by 0x805D600: _glp_lib_xmalloc (glplib07.c:60)
==2637==    by 0x80507B2: glp_create_prob (glpapi01.c:104)
==2637==    by 0x804C2DE: main (main.c:57)
==2637== 
==2637== LEAK SUMMARY:
==2637==    definitely lost: 0 bytes in 0 blocks
==2637==    indirectly lost: 0 bytes in 0 blocks
==2637==      possibly lost: 0 bytes in 0 blocks
==2637==    still reachable: 1,108 bytes in 1 blocks
==2637==         suppressed: 0 bytes in 0 blocks
==2637== 
==2637== For counts of detected and suppressed errors, rerun with: -v
==2637== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)

As it can be seen, there seems to remain 1.108bytes still reachable,
 maybe due to a missing free call. I guess that the environment block 
env (glplib01.c:67) has not been deallocated, that is, 
lib_free_env(void) may have not been called properly.

The example sample.c was also compiled and executed under valgrind 
and the same behavior was reported, as shown below:

address@hidden:/media/

hd/Otimizacao/glpk-4.42/examples$ valgrind --leak-check=full --show-reachable=yes ./sample
==3611== Memcheck, a memory error detector
==3611== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3611== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==3611== Command: ./sample
==3611==
*     0: obj =   0.000000000e+00  infeas =  0.000e+00 (0)
*     2: obj =   7.333333333e+02  infeas =  0.000e+00 (0)
OPTIMAL SOLUTION FOUND

z = 733.333; x1 = 33.3333; x2 = 66.6667; x3 = 0
==3611==
==3611== HEAP SUMMARY:
==3611==     in use at exit: 1,108 bytes in 1 blocks
==3611==   total heap usage: 80 allocs, 79 frees, 31,226 bytes allocated
==3611==
==3611== 1,108 bytes in 1 blocks are still reachable in loss record 1 of 1
==3611==    at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==3611==    by 0x407ADA3: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x407AF24: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x407C46B: ??? (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x40428C2: glp_create_prob (in /usr/lib/libglpk.so.0.23.0)
==3611==    by 0x8048804: main (in /media/hd/Otimizacao/glpk-4.42/examples/sample)
==3611==
==3611== LEAK SUMMARY:
==3611==    definitely lost: 0 bytes in 0 blocks
==3611==    indirectly lost: 0 bytes in 0 blocks
==3611==      possibly lost: 0 bytes in 0 blocks
==3611==    still reachable: 1,108 bytes in 1 blocks
==3611==         suppressed: 0 bytes in 0 blocks
==3611==
==3611== For counts of detected and suppressed errors, rerun with: -v
==3611== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 8)

Can I safely disregard this reported leak?
Thanks for your help.
Murilo