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

[Robbie Morrison]

Hello GLPK help 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.

Additional information has been posted to the GLPK bug
list, including the new output from 'valgrind'.

For those that do not know, 'valgrind' is a memory
debugger and profiler.  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

/* 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);

  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()

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