[Bug-glpk] Re: Minor memory leak / follow up

[Robbie Morrison]

Hello GLPK bug list (and Andrew)

I can confirm that GLPK does release all memory when
lib_free_env() is called following lpx_delete_prob(LPX*).

The necessary code modifications to 'sample.c' are
given below.

Output from the 'valgrind' memory debugger and profiler
are also shown for GLPK versions 4.11 (Ubuntu package)
and 4.17 (built from source).

It could be useful to include a footnote on page 13 of
'glpk.ps' manual to explain that not all memory is
released by lpx_delete_prob(LPX*).  A draft of some
text is provided.

I 'valgrind' all my code.  I find it useful to get a
clean result, because 'valgrind' can reveal coding
errors that naturally slip past the compiler and have
yet to make their presence felt at run-time.

with best wishes
Robbie

---------------------------------
 Modified code
---------------------------------

/* derived from sample.c */

#include <stdio.h>
#include <stdlib.h>

extern "C" {        // linkage advice for C++ compiler (as required)
#include <glpk.h>   /* API header */
#include <glplib.h> /* lib_free_env() */
}

int main()
{

  /* skip most code */

  lpx_delete_prob(lp);

  /* release remaining GLPK resources
   *
   * function: lib_free_env()
   * role: free any GLPK library environment resources still in use,
   *       including allocated memory and open streams
   * return: 0 = deinitialization successful, 1 = deinitialization not required
   * header: glplib.h (C++ needs extern "C" linkage)
   * source: glplib04.c (this file contains the primary documentation)
   */

  int ret = lib_free_env();
  switch (ret)
    {
    case 0:  printf("deinitialization successful\n"); break;
    case 1:  printf("deinitialization not required\n"); break;
    default: printf("unknown return from lib_free_env(): %d\n", ret);
    }

  return 0;

} // main()

---------------------------------
 GLPK 4.17
---------------------------------

$ valgrind --leak-check=yes --show-reachable=yes ./sample

  Memcheck, a memory error detector.
  Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
  Using LibVEX rev 1606, a library for dynamic binary translation.
  Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
  Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework.
  Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
  For more details, rerun with: -v

dmp_create_pool: warning: debug mode enabled
*     0:   objval =   0.000000000e+00   infeas =   0.000000000e+00 (0)
*     2:   objval =   7.333333333e+02   infeas =   0.000000000e+00 (0)
OPTIMAL SOLUTION FOUND

z = 733.333; x1 = 33.3333; x2 = 66.6667; x3 = 0
deinitialization successful

  ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
  malloc/free: in use at exit: 0 bytes in 0 blocks.
  malloc/free: 81 allocs, 81 frees, 34,529 bytes allocated.
  For counts of detected errors, rerun with: -v
  All heap blocks were freed -- no leaks are possible.

---------------------------------
 GLPK 4.11
---------------------------------

$ valgrind --leak-check=yes --show-reachable=yes ./sample

  Memcheck, a memory error detector.
  Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
  Using LibVEX rev 1606, a library for dynamic binary translation.
  Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
  Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework.
  Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
  For more details, rerun with: -v

*     0:   objval =   0.000000000e+00   infeas =   0.000000000e+00 (0)
*     2:   objval =   7.333333333e+02   infeas =   0.000000000e+00 (0)
OPTIMAL SOLUTION FOUND

z = 733.333; x1 = 33.3333; x2 = 66.6667; x3 = 0
deinitialization successful

  ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
  malloc/free: in use at exit: 0 bytes in 0 blocks.
  malloc/free: 86 allocs, 86 frees, 57,717 bytes allocated.
  For counts of detected errors, rerun with: -v
  All heap blocks were freed -- no leaks are possible.

---------------------------------
 Suggestion for footnote
---------------------------------

glpk.ps, page 13, last paragraph:

"Finally, the statement s37 calls the routine
glp_delete_prob, which frees all the memory allocated
to the problem object./1/"

/1/ Around 136 bytes of memory will remain allocated at
the close of main as part of a general support
environment created by GLPK.  If need be, this memory
can be released by adding the following line (after the
problem object has been deleted and before main
returns):

  lib_free_env();

The routine lib_free_env requires the addition of the
following header (set in an extern "C" block if
compiling under C++):

  #include <glplib.h>

[alternatively, the lib_free_env function declaration
could be copied to glplk.h and even promoted to
glp_lib_free_env]

>  --------------------------------------------------------
> Message: 2
> Date: Fri, 8 Jun 2007 05:49:23 +0400
> From: Andrew Makhorin <address@hidden>
> Subject: Re: [Bug-glpk] Minor memory leak
> To: Robbie Morrison <address@hidden>
> Cc: address@hidden, address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Robbie,
>
> Thank you for your report.
>
>> It seems that GLPK 4.11 and 4.17 leak a few bytes of
>> memory each time a problem is built.  This may not be a
>> significant issue, but it is probably worth logging.
>
>> The example used was based on sample.c and compiled
>> using g++.
>
>>  LEAK SUMMARY:
>>     definitely lost: 0 bytes in 0 blocks.
>>       possibly lost: 0 bytes in 0 blocks.
>>     still reachable: 124 bytes in 1 blocks.
>>          suppressed: 0 bytes in 0 blocks.
>
> This is not a bug.
>
> That memory block, which remains allocated, is the glpk library
> environment block; it is automatically allocated by the routine
> lib_init_env on the first call to any glpk api routine. It can be
> deallocated by the routine lib_free_env, which frees all resources
> used by glpk, however, normally this is not needed. This would be
> needed only in two cases: i) in a multi-threaded environment on
> terminating the thread, and ii) on processing SIGABORT signal.
>
> Andrew Makhorin
> ------------------------------

---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Institute for Energy Engineering (IET)
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]