[Cbc] "Index out of bounds" when pre-processing problems with SOSes
Dirk Eßer
essdir at web.de
Tue May 13 09:59:24 EDT 2014
Hello John,
the changes work fine, the problem with SOS is gone now, thank you very
much.
Unfortunately, it seems, that the problem with integer declarations
persists, despite me having thought, that it was gone (it was "eclipsed"
in our test suites by the problem with the SOSes, it seems):
#0 0x00007ffff60f8849 in raise () from /lib64/libc.so.6
#1 0x00007ffff60f9cd8 in abort () from /lib64/libc.so.6
#2 0x00007ffff60f1616 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007ffff60f16c2 in __assert_fail () from /lib64/libc.so.6
#4 0x00007ffff4ce09ed in OsiSolverInterface::findIntegers
(this=0x7d9798, justCount=false) at OsiSolverInterface.cpp:1978
#5 0x00007ffff448e37c in OsiClpSolverInterface::deleteCols
(this=0x7d94f0, num=2, columnIndices=0x7d3f30) at
OsiClpSolverInterface.cpp:3236
#6 0x00007ffff5335436 in CbcModel::AddIntegers (this=0x7fffffffc980)
at CbcModel.cpp:1306
#7 0x00007ffff533b812 in CbcModel::branchAndBound
(this=0x7fffffffc980, doStatistics=0) at CbcModel.cpp:2701
#8 0x00007ffff5625a87 in lp::detail::(anonymous
namespace)::solve_via_cbc (LP=...) at src/Expr_problem.cpp:674
(gdb) fr 4
#4 0x00007ffff4ce09ed in OsiSolverInterface::findIntegers
(this=0x7d9798, justCount=false) at OsiSolverInterface.cpp:1978
1978 assert (iColumn>=0&&iColumn<numberColumns);
(gdb) l
1973 for (iObject = 0;iObject<nObjects;iObject++) {
1974 OsiSimpleInteger * obj =
1975 dynamic_cast <OsiSimpleInteger *>(oldObject[iObject]) ;
1976 if (obj) {
1977 iColumn = obj->columnNumber();
1978 assert (iColumn>=0&&iColumn<numberColumns);
1979 marked[iColumn]=iObject;
1980 }
1981 }
1982 // make a large enough array for new objects
Poking around with GDB a little bit, it seems, that the problem here is
similar to the one with the SOSes (the column number in the declaration
object being larger than the number of columns remaining after
pre-processing). The call to "branchAndBound" in the stacktrace occurs
at a similar point during processing as it does in the driver file.
Unfortunately, I cannot reproduce it with the driver (neither with nor
without your modifications), and I am not yet sure, whether this is due
to the way I generate the MPS/LP files from dumps generated by our main
application, or whether there is still something done differently by the
application (when compared to the driver). Attached model should exhibit
the problem (when run using the driver) but doesn't. I compare the
driver against our actual application later.
Am 13.05.2014 14:25, schrieb John Forrest:
> Dirk,
>
> SOS with pre-processing is a bit delicate - I attach a modified driver
> which resets the SOS indices after preprocessing.
>
> I used a const_cast which is a bit naughty (but safe).
>
> John
> On 13/05/14 09:17, Dirk Eßer wrote:
>> Hi John,
>>
>> the driver attached to this mail fails (when fed the "test3.mps")
>> with the following stacktrace:
>>
>> #0 0x00007ffff4c43849 in raise () from /lib64/libc.so.6
>> #1 0x00007ffff4c44cd8 in abort () from /lib64/libc.so.6
>> #2 0x00007ffff553c655 in
>> __gnu_cxx::__verbose_terminate_handler() () from
>> /usr/lib64/libstdc++.so.6
>> #3 0x00007ffff553a7c6 in ?? () from /usr/lib64/libstdc++.so.6
>> #4 0x00007ffff553a7f3 in std::terminate() () from
>> /usr/lib64/libstdc++.so.6
>> #5 0x00007ffff553aa1e in __cxa_throw () from
>> /usr/lib64/libstdc++.so.6
>> #6 0x00007ffff6c77185 in indexError (index=2,
>> methodName="isInteger") at OsiClpSolverInterface.cpp:1447
>> #7 0x00007ffff6c7d02f in OsiClpSolverInterface::isInteger
>> (this=0x64d5e0, colNumber=2) at OsiClpSolverInterface.cpp:2756
>> #8 0x00007ffff7b86dd1 in CbcSOS::CbcSOS (this=0x629530,
>> model=0x7fffffffd860, numberMembers=2, which=0x64ce90,
>> weights=0x6488b0, identifier=0, type=1) at CbcSOS.cpp:67
>> #9 0x00007ffff7b4e0a0 in CbcModel::findIntegers
>> (this=0x7fffffffd860, startAgain=false, type=0) at CbcModel.cpp:10949
>> #10 0x00007ffff7b28f30 in CbcModel::branchAndBound
>> (this=0x7fffffffd860, doStatistics=0) at CbcModel.cpp:1920
>> #11 0x0000000000403e4e in main (argc=1, argv=0x7fffffffde88) at
>> user_driver.cpp:328
>>
>> on
>>
>> SMP x86_64 x86_64 x86_64 GNU/Linux
>> g++ (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
>> compiled against 2.8 of the CBC library
>>
>> We also observe this behaviour from within our main application,
>> which creates the problem instance programmatically (but whose actual
>> processing step is pretty close to what the driver does). Inspecting
>> the variables in frame #7, we find, that the number of columns is
>> reported to be 0. I am not sure, how this should be interpreted...
>>
>> There was a similar problem with integer declarations (which we
>> formerly did by adding OsiSimpleInteger objects), where the program
>> triggered an assertion from time to time. After switching the
>> declaration code to calls to "setInteger" on the
>> "OsiClpSolverInterface", that problem went away. Not sure, whether it
>> was related; IIRC, when this tended to happen, the reported column
>> count after pre-processing was not 0.
>>
>> Any help appreciated.
>>
>> Dirk
>>
>>
>>
>>
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cbc
>
>
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20140513/797ae23f/attachment.html>
More information about the Cbc
mailing list