Opened 7 years ago

Last modified 20 months ago

#19523 new defect

Adding constraints for the wrong MILP crashes Sage — at Version 5

Reported by: Jeroen Demeyer Owned by:
Priority: major Milestone: sage-7.3
Component: linear programming Keywords:
Cc: Yuan Zhou Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #19525 Stopgaps:

Status badges

Description (last modified by Matthias Köppe)

sage: p = MixedIntegerLinearProgram(solver="glpk")
sage: q = MixedIntegerLinearProgram(solver="glpk")
sage: q.add_constraint(p[0] <= 1)
Unhandled SIGABRT: An abort() occurred in Sage.
This probably occurred because a *compiled* component of Sage has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Sage will now terminate.

With #19525, this improves to not crashing Sage:

sage: sage: p = MixedIntegerLinearProgram(solver="glpk")
sage: sage: q = MixedIntegerLinearProgram(solver="glpk")
sage: sage: q.add_constraint(p[0] <= 1)
GLPKError                                 Traceback (most recent call last)
GLPKError: glp_set_mat_row: i = 1; len = 1; invalid row length 
Error detected in file glpapi01.c at line 760

This ticket is to actually fix the error completely or give a better error message.

Also a crash with the COIN backend.

And low-level error message with the PPL and InteractiveLP (#20296 ) backends.

The CVX backend silently adds a new variable that is accessible only to the backend:.

sage: sage: default_mip_solver("cvxopt")
sage: sage: p = MixedIntegerLinearProgram()
sage: sage: q = MixedIntegerLinearProgram()
sage: sage: q.add_constraint(p[0] <= 1)
sage: q.number_of_variables()

Change History (5)

comment:1 Changed 7 years ago by Jeroen Demeyer

Dependencies: #19525
Description: modified (diff)

comment:2 Changed 7 years ago by Nathann Cohen

Cc: Nathann Cohen added

comment:3 Changed 7 years ago by Jeroen Demeyer

Description: modified (diff)
Priority: criticalmajor

comment:4 Changed 7 years ago by Matthias Köppe

While MIPVariable objects know which MIP they belong to, their "components" gotten by p[0] etc. are elements of LinearFunctionsParent(base_ring), and do not remember their MIP (nor even their name). So with the current design it does not seem possible to catch the error of adding constraints to the wrong MIP. So unfortunately only lower-level error checking, catching out-of-bounds indices, is possible.

comment:5 Changed 7 years ago by Matthias Köppe

Description: modified (diff)
Note: See TracTickets for help on using tickets.