Re: [Help-glpk] Memory leak?

[Andrew Makhorin]

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

Yes, those 1108 bytes are occupied by the glpk environment block. It
is allocated implicitly on the very first call to any glpk api routine.
To deallocate it you need to call glp_free_env. Note, however, that
glp_free_env frees all the memory allocated by glpk and, thus,
invalidates all problem objects which are still exist. For more details
please see the glpk reference manual, Section "GLPK environment
routines".

> Can
>  I safely disregard this reported leak?

Yes. You can consider that 1K of memory as a static storage used
by glpk. Or just call glp_free_env at the end to clean up all glpk
traces.