Closed rodo-hf closed 3 years ago
Able to reproduce the bug in Linux, good, I'll be able to investigate it :)
Hi @rodo-hf , I think that this was fixed in 1.12, could you please check it ?
Hi @h-g-s ,
no, it is still same error (consider the new file):
` ERROR while running Cbc. Signal SIGSEGV caught. Getting stack trace. 0 cbc-c-darwin-x86-64.dylib 0x0000000133e08727 _Z15CbcCrashHandleri + 327 1 libsystem_platform.dylib 0x00007fff597e8b5d _sigtramp + 29 2 ??? 0x0000000000000000 0x0 + 0 3 cbc-c-darwin-x86-64.dylib 0x0000000133e93e7e _ZN8CbcModel15setBestSolutionEPKdidb + 1662 4 cbc-c-darwin-x86-64.dylib 0x0000000133debb8f _Z8CbcMain1iPPKcR8CbcModelPFiPS2_iER19CbcSolverUsefulData + 106015 5 cbc-c-darwin-x86-64.dylib 0x0000000133d4f215 Cbc_solve + 4805 6 libffi.dylib 0x00007fff571a6f6c ffi_call_unix64 + 76 7 ??? 0x000000012d9c7b38 0x0 + 5060197176
ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace. 0 cbc-c-darwin-x86-64.dylib 0x0000000133e08727 _Z15CbcCrashHandleri + 327 1 libsystem_platform.dylib 0x00007fff597e8b5d _sigtramp + 29 2 ??? 0x0a3637200a363731 0x0 + 735836199871461169 3 libsystem_c.dylib 0x00007fff596a26a6 abort + 127 4 cbc-c-darwin-x86-64.dylib 0x000000013428cb10 _ZNSt3__16vectorINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS4_IS6EEEC2ERKS8.cold.1 + 0 5 cbc-c-darwin-x86-64.dylib 0x0000000133e087cf _Z15CbcCrashHandleri + 495 6 libsystem_platform.dylib 0x00007fff597e8b5d _sigtramp + 29 7 ??? 0x0000000000000000 0x0 + 0 8 cbc-c-darwin-x86-64.dylib 0x0000000133e93e7e _ZN8CbcModel15setBestSolutionEPKdidb + 1662 9 cbc-c-darwin-x86-64.dylib 0x0000000133debb8f _Z8CbcMain1iPPKcR8CbcModelPFiPS2_iER19CbcSolverUsefulData + 106015 10 cbc-c-darwin-x86-64.dylib 0x0000000133d4f215 Cbc_solve + 4805 11 libffi.dylib 0x00007fff571a6f6c ffi_call_unix64 + 76 12 ??? 0x000000012d9c7b38 0x0 + 5060197176
`
Tested here, if I run with pypy3 it works, running with python3 I got an infeasible model... I'll investigate more
Hi @rodo-hf , 1.13 was released with some stability fixes, specially for MacOS, could you please test ?
works now!
Describe the bug Running a model with max_mip_gap=0.001 provides error 134. With max_mip_gap=0.01 it works.
To Reproduce Consider model.lp.txt with { "emphasis": 1, 'max_mip_gap': 0.001, 'solver_name': 'CBC', }, and { 'max_seconds': 500, }.
Expected behavior Taking into account longer runtime, we would expect to find a solution with any granularity of max_mip_gap, if there exists a feasible solution with lower granularity.
Desktop (please complete the following information):