help-glpk
[Top][All Lists]
Advanced

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

[Help-glpk] error handling in glpk


From: Andrew Makhorin
Subject: [Help-glpk] error handling in glpk
Date: Tue, 10 Nov 2015 16:25:22 +0300

On Mon, 2015-11-09 at 07:45 -0800, Jeroen Demeyer wrote:
> On 2015-11-09 00:08, Andrew Makhorin wrote:
> > The glpk reference manual says (6.1.13):
> >     If the hook routine returns, the application program is
> >     abnormally terminated. To prevent abnormal termination the hook
> >     routine may perform a global jump using the standard function
> >     longjmp, in which case the application program *must* call the
> >     routine glp_free_env.
> 
> I see. Unfortunately, this actually frees all memory allocated by GLPK 
> before which means that future calls to glp_delete_prob() for example 
> will generate an error. This makes it harder to use for me.
> 
> Jeroen.
> 

Just to clarify the design of error handling in glpk.

Generally there may be three types of errors.


I. Regular errors.

Example: the application calls glp_read_mps to read a mps file, but the
file does not exists.

In this case the glpk api routines indicate an error by means of the
return code.


II. Incorrect calls to glpk api routines.

Example: the application calls glp_set_col_bnds passing an invalid
column number.

In this case the glpk api routines indicate an error by a call to
glp_error which prints a message and abnormally terminates the
application.

(Heinrich suggests in this case to return a error code like for regular
errors. But for what? This case only means that the application has a
bug and should be terminated, because this error is like passing an
invalid pointer to memcmp or realloc.)


III. Internal bug in glpk

This case, which normally should never happen, is usually detected by
glp_assert macro that calls glp_error to print an error message and
abnormally terminate the application. The application may prevent
abnormal termination, but in that case it should call glp_free_env to
invalidate the glpk environment, because there are no more guarantees
that internal glpk data structures are consistent. (In glpk memory
allocation and file handling are controlled on a low level that allows
correctly freeing all the resources even in this case.)


Andrew Makhorin





reply via email to

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