ERGO-Code
Crash with EXC_BAD_ACCESS in HighsSymmetryDetection::run on macOS M1 with symmetry detection enabled
Running a symmetric model using HiGHS via HighsPy crashes on macOS M1 (Apple Silicon) with EXC_BAD_ACCESS in HighsSymmetryDetection::run. This occurs only when symmetry detection is enabled and does not reproduce on Linux or Windows.
- Platform: macOS 15.5 (24F74), Apple M1 (ARM64)
- Python: 3.13
- HighsPy version: 1.11.0
- Symmetry detection option: Enabled (mip_detect_symmetry = true)
- Reproducibility: Non-deterministic; happens sporadically on repeated runs
- Workaround: Disabling symmetry detection (mip_detect_symmetry = false) avoids the crash
Steps to reproduce, albeit non determenistic:
import highspy
from ortools.math_opt.python import mathopt
# Number of workers/tasks (increase for more symmetry)
n = 10
model = mathopt.Model()
x = [
[model.add_binary_variable(name=f"x{i+1}{j+1}") for j in range(n)] for i in range(n)
]
for i in range(n):
model.add_linear_constraint(sum(x[i][j] for j in range(n)) == 1)
for j in range(n):
model.add_linear_constraint(sum(x[i][j] for i in range(n)) == 1)
model.minimize(x[0][0])
highs_model = highspy.Highs()
highs_model.setOptionValue("log_to_console", True)
# highs_model.setOptionValue("mip_detect_symmetry", True)
# Create variables and objective
assert all(i == v.id for i, v in enumerate(model.variables()))
for v in model.variables():
obj_coeff = model.objective.get_linear_coefficient(v)
match v.integer, v.lower_bound, v.upper_bound:
case True, 0, 1:
highs_model.addBinary(name=v.name, obj=obj_coeff)
case True, lb, ub:
highs_model.addIntegral(name=v.name, lb=lb, ub=ub, obj=obj_coeff)
case False, lb, ub:
highs_model.addVariable(
name=v.name, lb=v.lower_bound, ub=v.upper_bound, obj=obj_coeff
)
highs_model.changeObjectiveOffset(model.objective.offset)
# Create constraints
for c in model.linear_constraints():
if next(c.terms(), None) is None:
continue
indices, coeffs = zip(
*((t.variable.id, t.coefficient) for t in c.terms()), strict=True
)
highs_model.addRow(
(c.lower_bound if c.lower_bound != float("-inf") else -highspy.kHighsInf),
(c.upper_bound if c.upper_bound != float("inf") else highspy.kHighsInf),
len(indices),
indices,
coeffs,
)
highs_model.solve()
The code is with ortools and highspy, as I am not able to reproduce it only with highspy. We are using ortools to be able to swap the solvers if necessary, but this wierd construction is necessary, since ortools does not pass solution hint to Highs directly (issue).
Run the code with
lldb -- python script.py
and after hitting run I get
Process 17927 stopped
* thread #31, stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
frame #0: 0x0000000135efa8c0 _core.cpython-313-darwin.so`HighsSymmetryDetection::run(HighsSymmetries&) + 2096
_core.cpython-313-darwin.so`HighsSymmetryDetection::run:
-> 0x135efa8c0 <+2096>: ldr x8, [x25, #0x30]
0x135efa8c4 <+2100>: cbz x8, 0x135efa168 ; <+216>
0x135efa8c8 <+2104>: ldr x8, [x8, #0x38]
0x135efa8cc <+2108>: tbz w8, #0x1, 0x135efa168 ; <+216>
Target 0: (python) stopped.
and after typing bt I get
* thread #31, stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
* frame #0: 0x0000000135efa8c0 _core.cpython-313-darwin.so`HighsSymmetryDetection::run(HighsSymmetries&) + 2096
frame #1: 0x0000000135ea4db4 _core.cpython-313-darwin.so`___lldb_unnamed_symbol6272 + 56
frame #2: 0x00000001250f29b8 libhighs.1.dylib`HighsSplitDeque::runStolenTask(HighsTask*) + 80
frame #3: 0x00000001250f2344 libhighs.1.dylib`HighsTaskExecutor::run_worker(int, HighsTaskExecutor*) + 276
frame #4: 0x0000000135dbf994 _core.cpython-313-darwin.so`___lldb_unnamed_symbol5693 + 60
frame #5: 0x00000001983bec0c libsystem_pthread.dylib`_pthread_start + 136
which likely means there might be some race conditions.
Update: I attach an .mps file of the model model.mps.zip, maybe this somehow help to you.
If you need any assistance with getting more debug info to narrow it down, I am happy to help.
Thanks for a great work on HIGHS!
I added an .mps file of model to the issue description. As I mentioned, it is very difficult to reproduce, and the issue appears always when Highs is called in our internal project. The isolation of code into small script to reproduce the issue does not really help and it almost never fails. It is very strange. If you have any other idea, just let me know.
