GLPK crash when calling solvers.lp

[Benjamin Sperisen]

Hi all,

I have a program that has to solve many different linear programming problems one after another, repeatedly calling solvers.lp(). In general, using solver='glpk' is much faster than the default solver, but for a number of these problems it crashes with output like the following:

Assertion failed: trow[csa->q] != 0.0

Error detected in file simplex/spxprim.c at line 919

[bsperisen-PC:17130] *** Process received signal ***

[bsperisen-PC:17130] Signal: Aborted (6)

[bsperisen-PC:17130] Signal code:  (-6)

[bsperisen-PC:17130] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7ff6874d13d0]

[bsperisen-PC:17130] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7ff68712c418]

[bsperisen-PC:17130] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7ff68712e01a]

[bsperisen-PC:17130] [ 3] /usr/lib/x86_64-linux-gnu/libglpk.so.36(glp_error_+0x0)[0x7ff64e8162c0]

[bsperisen-PC:17130] [ 4] /usr/lib/x86_64-linux-gnu/libglpk.so.36(+0xa4183)[0x7ff64e82c183]

[bsperisen-PC:17130] [ 5] /usr/lib/x86_64-linux-gnu/libglpk.so.36(glp_simplex+0x6b3)[0x7ff64e793673]

[bsperisen-PC:17130] [ 6] /home/bsperisen/.python-eggs/cvxopt-1.1.8-py2.7-linux-x86_64.egg-tmp/cvxopt/glpk.so(+0x3833)[0x7ff64ea61833]

[bsperisen-PC:17130] [ 7] python(PyEval_EvalFrameEx+0x68a)[0x4c41da]

[bsperisen-PC:17130] [ 8] python(PyEval_EvalCodeEx+0x255)[0x4c22e5]

[bsperisen-PC:17130] [ 9] python[0x4de9b8]

[bsperisen-PC:17130] [10] /home/bsperisen/.pyxbld/lib.linux-x86_64-2.7/opt_eqba.so(+0x95a0)[0x7ff66de885a0]

[bsperisen-PC:17130] [11] /home/bsperisen/.pyxbld/lib.linux-x86_64-2.7/opt_eqba.so(+0x7376)[0x7ff66de86376]

[bsperisen-PC:17130] [12] /home/bsperisen/.pyxbld/lib.linux-x86_64-2.7/opt_eqba.so(+0x1fa65)[0x7ff66de9ea65]

[bsperisen-PC:17130] [13] /home/bsperisen/.pyxbld/lib.linux-x86_64-2.7/opt_eqba.so(+0x2ee60)[0x7ff66deade60]

[bsperisen-PC:17130] [14] python(PyEval_EvalFrameEx+0x68a)[0x4c41da]

[bsperisen-PC:17130] [15] python(PyEval_EvalFrameEx+0x5dff)[0x4c994f]

[bsperisen-PC:17130] [16] python(PyEval_EvalFrameEx+0x5dff)[0x4c994f]

[bsperisen-PC:17130] [17] python(PyEval_EvalCodeEx+0x255)[0x4c22e5]

[bsperisen-PC:17130] [18] python(PyEval_EvalCode+0x19)[0x4c2089]

[bsperisen-PC:17130] [19] python[0x4f1e6f]

[bsperisen-PC:17130] [20] python(PyRun_FileExFlags+0x82)[0x4ec802]

[bsperisen-PC:17130] [21] python(PyRun_SimpleFileExFlags+0x191)[0x4eaf81]

[bsperisen-PC:17130] [22] python(Py_Main+0x68a)[0x49e36a]

[bsperisen-PC:17130] [23] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ff687117830]

[bsperisen-PC:17130] [24] python(_start+0x29)[0x49dbf9]

[bsperisen-PC:17130] *** End of error message ***

However, rerunning it with the default solver (solver=None) manages to solve these same problems (albeit slowly).

Short of fixing whatever is going wrong with GLPK, I'd like to try GLPK first and then if it crashes, redo it with the default solver -- basically what I've been doing manually. If the above error threw an exception, I could catch it and then try with the default solver, but it seems to be a hard crash (my "try" clause around the solvers.lp() call doesn't do any good).

Is there a way to throw an exception when this happens rather than a hard crash? I was thinking this might involve changing the CVXOPT source code but not sure....

Thanks!

Ben

[Jean-Paul Davis]

Did you ever find a satisfactory solution to this problem?  I have the same issue, running thousands of times and only want to fall back on default solver if needed.  Some failures can be caught by looking at the "status" key returned by solvers.lp, but not this one.

Jean-Paul

On Wednesday, August 31, 2016 at 4:58:59 AM UTC-6, Benjamin Sperisen wrote:

Hi all,

I have a program that has to solve many different linear programming problems one after another, repeatedly calling solvers.lp(). In general, using solver='glpk' is much faster than the default solver, but for a number of these problems it crashes with output like the following:

Assertion failed: trow[csa->q] != 0.0

Error detected in file simplex/spxprim.c at line 919

[Dima Pasechnik]

It might be a good idea to post an example LP on which you get this error.

Perhaps it is not hard to fix-- an example showing the problem is surely very important in this regard.