BUG: segfault adding column, row, column

[odow]

Examples are in Julia, but using the C API.

We get lots of dimension validation problems:

julia> using HiGHS

julia> highs = Highs_create()
Ptr{Nothing} @0x00007fb444bce200

julia> Highs_addCol(highs, 0.0, -Inf, Inf, 0, C_NULL, C_NULL)
0

julia> Highs_addRow(highs, 2.0, Inf, 1, [0], [1.0])
0

julia> Highs_addCol(highs, 0.0, -Inf, Inf, 0, C_NULL, C_NULL)
ERROR:   LP dimension validation (returnFromHighs) fails on a_matrix.num_col_ = 1 != 2 = num_col
ERROR:   LP dimension validation (returnFromHighs) fails
LP Dimension error in returnFromHighs()
0

julia> Highs_run(highs)
Presolving model
0 rows, 0 cols, 0 nonzeros
0 rows, 0 cols, 0 nonzeros
Presolve : Reductions: rows 0(-1); columns 0(-2); elements 0(-0) - Reduced to empty
Solving the original LP from the solution after postsolve
Model   status      : Optimal
Objective value     :  0.0000000000e+00
HiGHS run time      :          0.00
ERROR:   Matrix dimension validation fails on start size = 2 < 3 = num vectors + 1
ERROR:   LP dimension validation (returnFromHighs) fails on a_matrix dimensions
ERROR:   LP dimension validation (returnFromHighs) fails on a_matrix.num_col_ = 1 != 2 = num_col
ERROR:   LP dimension validation (returnFromHighs) fails
LP Dimension error in returnFromHighs()
0

julia> Highs_destroy(highs)

However, add an innocuous call to changeObjectiveOffset and we get:

julia> using HiGHS

julia> highs = Highs_create()
Ptr{Nothing} @0x00007fb444bce200

julia> Highs_changeObjectiveOffset(highs, 0.0)
0

julia> Highs_addCol(highs, 0.0, -Inf, Inf, 0, C_NULL, C_NULL)
0

julia> Highs_addRow(highs, 2.0, Inf, 1, [0], [1.0])
0

julia> Highs_addCol(highs, 0.0, -Inf, Inf, 0, C_NULL, C_NULL)
ERROR:   LP dimension validation (returnFromHighs) fails on a_matrix.num_col_ = 1 != 2 = num_col
ERROR:   LP dimension validation (returnFromHighs) fails
LP Dimension error in returnFromHighs()
0

julia> Highs_run(highs)
Presolving model
0 rows, 0 cols, 0 nonzeros
0 rows, 0 cols, 0 nonzeros
Presolve : Reductions: rows 0(-1); columns 0(-2); elements 0(-1143224706) - Reduced to empty
Solving the original LP from the solution after postsolve

signal (11): Segmentation fault: 11
in expression starting at REPL[14]:1
_ZN7HFactor12setupGeneralEiiiPKiS1_PKdPiddiPK15HighsLogOptionsbi at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN11HSimplexNla5setupEPK7HighsLpPiPK12HighsOptionsP10HighsTimerP20HighsSimplexAnalysisPK17HighsSparseMatrixd at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN4HEkk33initialiseSimplexLpBasisAndFactorEb at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN4HEkk18initialiseForSolveEv at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN4HEkk5solveEb at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_Z14solveLpSimplexR19HighsLpSolverObject at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_Z7solveLpR19HighsLpSolverObjectNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN5Highs11callSolveLpER7HighsLpNSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEE at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
_ZN5Highs3runEv at /Users/oscar/.julia/artifacts/ab64ac36595b305c3a5a850d5310f61cccee7782/lib/libhighs.dylib (unknown line)
Highs_run at /Users/oscar/.julia/dev/HiGHS/src/gen/libhighs.jl:47

[jajhall]

I reproduce the reports of LP dimension validation - and there's an assert triggered earlier in debug - but not the segfault with th innocuous call to changeObjectiveOffset. However valgrind reports a memory error that, I guess, manifests itself for you as a segfault.

[odow]

Yeah our segfaults can be quite hard to reproduce given the cross-compilation story.