#12309: GLPK crashes or hangs on certain inputs
----------------------------------+-----------------------------------------
Reporter: john_perry | Owner: ncohen
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: linear programming | Keywords:
Work_issues: | Upstream: Reported upstream.
Developers deny it's a bug.
Reviewer: | Author:
Merged: | Dependencies:
----------------------------------+-----------------------------------------
Changes (by john_perry):
* status: new => needs_review
Old description:
> The attached sage script (`inhomogeneous_bug_test.py`) creates a linear
> system that
>
> * crashes Sage if the variables are continuous, and
> * hangs Sage if the variables are integer.
>
> Nathann determined that this was a bug with GLPK, the underlying solver.
> I have attached a C++ program (`glpk_bug.cpp`) that reproduces the bug
> directly via the GLPK library, and passed it on to the developers.
>
> I can't resist the temptation to say that the developers don't consider
> this a bug, but a feature; see
>
> [http://lists.gnu.org/archive/html/bug-glpk/2012-01/threads.html This
> thread on the bug-glpk mailing list archive]
>
> and
>
> [http://en.wikibooks.org/wiki/GLPK/Known_issues#Unbounded_integer_variables
> GLPK/Known Issues]
>
> where they call this behavior ''essentially innate.'' The workaround is
> to set upper bounds.
>
> Sage's documentation should provide this information to the user, and
> suggest the workaround. We should also try trapping the exception, and
> notifying the user.
New description:
The attached sage script (`inhomogeneous_bug_test.py`) creates a linear
system that
* crashes Sage if the variables are continuous, and
* hangs Sage if the variables are integer.
Nathann determined that this was a bug with GLPK, the underlying solver. I
have attached a C++ program (`glpk_bug.cpp`) that reproduces the bug
directly via the GLPK library, and passed it on to the developers.
I can't resist the temptation to say that the developers don't consider
this a bug, but a feature; see
[http://lists.gnu.org/archive/html/bug-glpk/2012-01/threads.html This
thread on the bug-glpk mailing list archive]
and
[http://en.wikibooks.org/wiki/GLPK/Known_issues#Unbounded_integer_variables
GLPK/Known Issues]
where they call this behavior ''essentially innate.'' The workaround is to
set upper bounds.
Sage's documentation should provide this information to the user, and
suggest the workaround. We should also try trapping the exception, and
notifying the user.
'''Apply''':
trac_12309.patch
--
Comment:
The patch I am ''about'' to upload (not the one I just finished uploading)
adds the preprocessing option, an exception for preprocessing failure, a
`sig_str()` and `sig_off()` pair that catch the crash on the infeasible
system in the example, documentation of the new solver option, and a
doctest that raises the new exception. The doctest passes on my machine.
In short, it does everything the ticket asked for. Needs review!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12309#comment:2>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
