Running cbc 2.8.12 (could not find in the version list) I have encountered memory violation
Cbc0010I After 204000 nodes, 12 on tree, 3.4028235e+38 best solution, best possible 8073.3801 (1342.74 seconds)
Cbc0010I After 205000 nodes, 11 on tree, 3.4028235e+38 best solution, best possible 8073.3801 (1348.46 seconds)
Cbc0010I After 206000 nodes, 8 on tree, 3.4028235e+38 best solution, best possible 8298.4579 (1354.24 seconds)
Cbc0001I Search completed - best objective 3.402823466385289e+38, took 19355815 iterations and 869001 nodes (1359.25 seconds)
Cbc0032I Strong branching done 171648 times (2422070 iterations), fathomed 4617 nodes and fixed 12697 variables
Cbc0041I Maximum depth 27, 0 variables fixed on reduced cost (662131 nodes in complete fathoming taking 6361958 iterations)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffede6a700 (LWP 26565)]
0x00007ffff0e66be2 in CbcMain1 (argc=3, argv=0x7fffe8134640, model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:6641
6641 solution2[jColumn] = solution[i];
(gdb) bt
#0 0x00007ffff0e66be2 in CbcMain1 (argc=3, argv=0x7fffe8134640, model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:6641
#1 0x00007ffff0e4e1b7 in callCbc1 (input2=0x7ffff1c5124f "-solve", model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:1130
#2 0x00007ffff0e4de0a in callCbc (input2=0x7ffff1c5124f "-solve", babSolver=...) at CbcSolver.cpp:1035
In my case a problem was infeasible and bestSolution() == solution == nullptr. Because there is no checks for that in the code above 6641 an attempt to access triggered coredump.
I believe the code connected with solution2 may be simply removed, I saw no usage for solution2. I removed locally and it seemed to work. (if not take into account some asserts i.e.
Cbc0010I After 206000 nodes, 8 on tree, 3.4028235e+38 best solution, best possible 8298.4579 (1356.03 seconds)
Cbc0001I Search completed - best objective 3.402823466385289e+38, took 19355815 iterations and 869001 nodes (1361.02 seconds)
Cbc0032I Strong branching done 171648 times (2422070 iterations), fathomed 4617 nodes and fixed 12697 variables
Cbc0041I Maximum depth 27, 0 variables fixed on reduced cost (662131 nodes in complete fathoming taking 6361958 iterations)
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
python: CbcSolver.cpp:6769: int CbcMain1(int, const char**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&): Assertion `saveSolver->isProvenOptimal()' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffede6a700 (LWP 29815)]
0x00007ffff782cbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff782cbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff782ffc8 in __GI_abort () at abort.c:89
#2 0x00007ffff7825a76 in __assert_fail_base (fmt=0x7ffff79772b0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7ffff279805a <error: Cannot access memory at address 0x7ffff279805a>, file=file@entry=0x7ffff2796e04 <error: Cannot access memory at address 0x7ffff2796e04>,
line=line@entry=6769,
function=function@entry=0x7ffff2799400 <CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&)::__PRETTY_FUNCTION__> <error: Cannot access memory at address 0x7ffff2799400>) at assert.c:92
)
I hope this information will be helpful. Sorry I can not share exact problem to reproduce because it contains confidential data. The bug triggers very rare; even slightly modified problems passed successfully.
Hello.
Running cbc 2.8.12 (could not find in the version list) I have encountered memory violation
In my case a problem was infeasible and bestSolution() == solution == nullptr. Because there is no checks for that in the code above 6641 an attempt to access triggered coredump.
I believe the code connected with solution2 may be simply removed, I saw no usage for solution2. I removed locally and it seemed to work. (if not take into account some asserts i.e.
I hope this information will be helpful. Sorry I can not share exact problem to reproduce because it contains confidential data. The bug triggers very rare; even slightly modified problems passed successfully.
Thanks.