# Possible bug: GLPKError/assertion failed

Hello, Sage Community!

Recently, while trying to help one of the users of this forum, I wrote this code. As you can see, the MILP is defined as expected.

That was a few weeks ago. Just now, I have noticed that adding p.solve() produces an error/exception:

GLPKError: Assertion failed: j->lb < j->ub

Error detected in file glpnpp03.c at line 2134

According to this, the problem seems to be in a C (maybe Cython) subroutine, which I am not able to modify. The strange thing is that defining this same MILP, manually, using the data showed there, does not produce any error! That what makes me think this is a bug.

Here is the complete traceback:

---------------------------------------------------------------------------
GLPKError                                 Traceback (most recent call last)
10 p.show() # this is just to confirm we did it right
---> 11 p.solve()

/home/sc_serv/sage/local/lib/python2.7/site-packages/sage/numerical/mip.pyx in sage.numerical.mip.MixedIntegerLinearProgram.solve (build/cythonized/sage/numerical/mip.c:15815)()
2259         """
2260         if log is not None: self._backend.set_verbosity(log)
-> 2261         self._backend.solve()
2262         return self._backend.get_objective_value()
2263

/home/sc_serv/sage/local/lib/python2.7/site-packages/sage/numerical/backends/glpk_backend.pyx in sage.numerical.backends.glpk_backend.GLPKBackend.solve (build/cythonized/sage/numerical/backends/glpk_backend.c:9430)()
1060         if ((self.simplex_or_intopt == glp_intopt_only)
1061             or (self.simplex_or_intopt == glp_simplex_then_intopt) and (solution_status != GLP_UNDEF) and (solution_status != GLP_NOFEAS)):
-> 1062             sig_on()
1063             solve_status = glp_intopt(self.lp, self.iocp)
1064             solution_status = glp_mip_status(self.lp)

GLPKError: Assertion failed: j->lb < j->ub
Error detected in file glpnpp03.c at line 2134


It's working well with cplex and we get the obvious solution x[i] = 0. I tried with PPL which is complaining that bounds must be constant, i.e., not oo. So I used 10 instead of oo and solved it with PPL. Then I tried again with GLPK using 10 instead of oo and got a solution. So there might be something wrong in the way the backend handles oo.