Segmentation fault when solving a (quadratic convex) nonlinear problem in a memory-limited Docker

[Rastaban-TzW]

Describe the bug
When solving a nonlinear optimization problem in a Docker, with memory limits dictated by e.g. -m 4g, the default SCIP build sometimes (50%+) crashes with a segfault, or a bad free(). Furthermore, this "core dump" means that the entire process dies, and cannot be caught by Python.

In brief, something in METIS (in the nonlinear heuristics) is causing this issue.

To Reproduce
Inside a docker created with a memory limit, create and solve a nonlinear model (quadratic convex is fine).
I am not sure whether the size or complexity of the model matters -- still testing that. An anonymized problem file that replicates this problem is attached in comments.

Expected behavior
Normal solution

Mitigation (from BUGREPORT)

• Switch MUMPS off METIS ordering — SCIP nlpi/ipopt/optfile = "ipopt.opt" with
  mumps_pivot_order 0 (AMD) in that file. Avoids the METIS code path while keeping
  all NLP heuristics (incl. nlpdiving), so no primal-heuristic loss. Held 16/16
  solves where the METIS default / mumps_pivot_order 5 crash on loop 1. Note this is
  a path-avoidance workaround (the METIS overflow is still present, just not triggered),
  and AMD may give slightly different factorization performance than METIS.

System

• OS: Docker (python:3.13-slim)
• Version 6.2.1 (latest)
• SCIP version: bundled
• How did you install pyscipopt? PyPi

Additional context
Attached is a more detailed writeup co-authored with Claude, complete with long gdb thread dumps.

SCIP_BUGREPORT.md

Note: later testing showed MPEC is not the only heuristic that causes this. See comment below.

As well as the Python file used.

repro_reval_segfault.py

[Rastaban-TzW]

This is almost certainly a pure SCIP issue, actually. Should this issue be moved over there?

[Rastaban-TzW]

Attaching anonymized MPS file replicating this problem -- although you will have to remove the .txt extension, of course.

You can supply this file to the repro script using --problem reval-anon.mps.

reval-anon.mps.txt

[Joao-Dionisio]

Hey @Rastaban-TzW , thanks for the bug report!

This is almost certainly a pure SCIP issue, actually. Should this issue be moved over there?

Yeah, if that is the case, I think it'd be better hosted over there. Just FYI, there's a pretty big conference going on at the moment (IFORS), so it may take a little bit longer to answer.

[Rastaban-TzW]

Confirming that MPEC is not the only heuristic that causes this. Claude below:

Correction — disabling MPEC alone does not avoid this crash.

My original report claimed MPEC was the only heuristic that pulls SCIP into the Ipopt→MUMPS→METIS path. That's wrong. With heuristics/mpec/freq = -1, the crash still fires on the first solve — nlpdiving reaches the identical NLP path and corrupts the heap the same way:

munmap_chunk(): invalid pointer
…
#8 gk_free ()
#9 libmetis__rpqFree () → #12 libmetis__Refine2WayNode → #20 METIS_NodeND
#22 dmumps… → #27 Ipopt::MumpsSolverInterface::SymbolicFactorization()
#40 nlpiSolveIpopt → #41 SCIPsolveNLPParam → #42 heurExecNlpdiving
#43 SCIPprimalHeuristics → #45 SCIPsolve

The abort site also varies across runs (free(): invalid pointer, munmap_chunk(): invalid pointer, and a malloc.c chunk_main_arena assertion) — all consistent with a single heap overflow whose trampled chunk header is hit by whichever free/malloc comes next, independent of the specific heuristic.

Corrected workarounds: disabling all NLP-based heuristics (mpec, nlpdiving, subnlp, multistart) removes the heuristic entry points; the robust fix is reformulating the model to drop the quadratic term entirely (squared-L2 → L1), so the NLP solver is never invoked.

[Rastaban-TzW]

A helpful tip from the linked issue helped me find a much better workaround. Report, script, and original post updated.