help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Error detected in file ..\src\glplib07.c at line 147


From: Andrew Makhorin
Subject: Re: [Help-glpk] Error detected in file ..\src\glplib07.c at line 147
Date: Mon, 1 Dec 2008 23:27:36 +0300

> The example t1.cs was posted in February see:

> http://lists.gnu.org/archive/html/help-glpk/2008-02/msg00065.html

The glpk dynamic library name, libglpk.so, indicates that that was a
GNU/Linux compilation. Under GNU/Linux (as well as under Cygwin) glpk
does not use the thread local storage and stores a pointer to the library
environment block in a static location. In this case the glpk library
environment may be freed only with an explicitly call to glp_free_env.

If glpk is compiled with a native Windows compiler like MSVC, it uses
the thread local storage and frees its library environment automatically
on receiving the reason DLL_THREAD_DETACH or DLL_PROCESS_DETACH passed
to DllMain. This works only if: i) there is the only thread in the
process; ii) once the thread has been terminated, no calls to glpk api
routines are assumed, because all problem objects are automatically
invalidated by glp_free_env called from DllMain.

I am not sure about implementation of C++ and C# in MSVC, because I am
not interested in that. However, it looks like desctructors are called
*after* the thread has finished, even if it is the only thread in the
process. So, if a destructor calls glp_delete_prob, it passes a pointer
to a problem object, which has been invalidated by glp_free_env, that
causes an error in an internal glpk routine.

Since glpk api routines must not be be called from different threads,
I decided just to remove DllMain feature and use a static location to
keep a pointer to the glpk library environment on all platforms,
including MS Windows.

> when the call to glp_delete_prob in the destrutor worked fine. Maybe
> glpk has changed since 4.23 so that it is no longer needed, if you are
> confident that glpk always deletes it now. For the benefit of existing
> code if glpk can determine when it is needed and when it isn't that would
> be best.

There are two ways to free memory and other resources used by glpk:
either to call glp_delete_prob, which frees the memory allocated to a
particular problem object, or to call glp_free_env, which frees all the
memory allocated by glpk routines; in the latter case all program
objects created by glpk routines become invalid.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]