Error message is not understandable - what(): std::bad_array_new_length is not easy to debug

[PMLP-novo]

Describe the bug I developing a larger model and for some instances of the model I get the following error message. But it is extremly hard to debug this based on the error message. Using Python

Welcome to the CBC MILP Solver
Version: devel
Build Date: Nov 15 2020

Starting solution of the Linear programming relaxation problem using Dual Simplex

Coin0506I Presolve 275 (-16608) rows, 750 (-14574) columns and 2834 (-48660) elements
Clp0014I Perturbing problem by 0.001% of 37.947332 - largest nonzero change 0.00029362761 ( 0.001857064%) - largest zero change 0.00029208348
Clp0000I Optimal - objective value 168.67521
Coin0511I After Postsolve, objective 168.67521, infeasibilities - dual 0 (0), primal 0 (0)
Clp0032I Optimal objective 168.6752137 - 202 iterations time 0.032, Presolve 0.03
terminate called after throwing an instance of 'std::bad_array_new_length'
  what():  std::bad_array_new_length

ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/root/.local/share/virtualenvs/planner-_Xae74OV/lib/python3.7/site-packages/mip/libraries/lin64/libCbcSolver.so(_Z15CbcCrashHandleri+0x14c) [0x7f2c35b3783c]
/lib/x86_64-linux-gnu/libc.so.6(+0x37840) [0x7f2c5621c840]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b) [0x7f2c5621c7bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121) [0x7f2c56207535]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8c983) [0x7f2c3c55c983]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x928c6) [0x7f2c3c5628c6]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92901) [0x7f2c3c562901]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92b34) [0x7f2c3c562b34]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x91992) [0x7f2c3c561992]
./libCbc.so.0(+0x4cf85) [0x7f2c357c0f85]

[WencesVillegasMarset]

Hi @PMLP-novo did you find a solution to this issue? I have bumped into the same error myself.

Using COINOR-CBC 2.10.5 and PuLP 2.4.

[tkralphs]

Based on that error message, this looks like a bug in Cbc. To have any chance of debugging it, we would need a way to replicate. If you can write the model to a file and reproduce the error in stand-alone Cbc, it would probably be relatively easy to track down.

[WencesVillegasMarset]

Hi @tkralphs thanks for your response! I solved it by setting threads to 1 for COIN_CMD solver.

Nevertheless I'll try to reproduce the error! in order to track it down.

[maltebehr]

I think I stumbled across the exact same bug. It seems to occur when there are strictly more than 1024 SOS1 constrains for binary variables. Here is a minimal example reproducing the error:

import mip

def main():
    n = 1025  # bug occurs for n>1024
    model = mip.Model()
    var_1 = [model.add_var(var_type=mip.BINARY) for _ in range(n)]
    var_2 = [model.add_var(var_type=mip.BINARY) for _ in range(n)]
    for i in range(n):
        model.add_sos([(var_1[i], 0), (var_2[i], 1)], 1)
    model.objective = mip.xsum(var_1)
    model.optimize()

if __name__ == '__main__':
    main()

This produces:

Welcome to the CBC MILP Solver 
Version: devel 
Build Date: Nov 15 2020 

Starting solution of the Linear programming relaxation problem using Primal Simplex

Clp0000I Optimal - objective value 0
Clp0032I Optimal objective 0 - 0 iterations time 0.012, Idiot 0.01
terminate called after throwing an instance of 'std::bad_array_new_length'
  what():  std::bad_array_new_length

ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/.../lib/python3.8/site-packages/mip/libraries/lin64/libCbcSolver.so(_Z15CbcCrashHandleri+0x14c) [0x7f8902c5283c]
/lib64/libc.so.6(+0x3da60) [0x7f8911061a60]
/lib64/libc.so.6(gsignal+0x145) [0x7f89110619d5]
/lib64/libc.so.6(abort+0x116) [0x7f891104a8a4]
./libstdc++.so.6(+0x74c4b) [0x7f8901412c4b]
./libstdc++.so.6(+0x72a76) [0x7f8901410a76]
./libstdc++.so.6(+0x72ae1) [0x7f8901410ae1]
./libstdc++.so.6(+0x72d44) [0x7f8901410d44]
./libstdc++.so.6(+0x71a62) [0x7f890140fa62]
./libCbc.so.0(+0x4cf85) [0x7f89028dbf85]
...

I run Fedora 33 (x86-64)

[TPreece101]

Does anyone have any solutions or workarounds for this? I've just hit this same problem.