<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi John,<br>
<br>
the driver attached to this mail fails (when fed the "test3.mps")
with the following stacktrace:<br>
<blockquote><small><font face="Courier New, Courier, monospace">#0
0x00007ffff4c43849 in raise () from /lib64/libc.so.6<br>
#1 0x00007ffff4c44cd8 in abort () from /lib64/libc.so.6<br>
#2 0x00007ffff553c655 in
__gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6<br>
#3 0x00007ffff553a7c6 in ?? () from /usr/lib64/libstdc++.so.6<br>
#4 0x00007ffff553a7f3 in std::terminate() () from
/usr/lib64/libstdc++.so.6<br>
#5 0x00007ffff553aa1e in __cxa_throw () from
/usr/lib64/libstdc++.so.6<br>
#6 0x00007ffff6c77185 in indexError (index=2,
methodName="isInteger") at OsiClpSolverInterface.cpp:1447<br>
#7 0x00007ffff6c7d02f in OsiClpSolverInterface::isInteger
(this=0x64d5e0, colNumber=2) at OsiClpSolverInterface.cpp:2756<br>
#8 0x00007ffff7b86dd1 in CbcSOS::CbcSOS (this=0x629530,
model=0x7fffffffd860, numberMembers=2, which=0x64ce90,
weights=0x6488b0, identifier=0, type=1) at CbcSOS.cpp:67<br>
#9 0x00007ffff7b4e0a0 in CbcModel::findIntegers
(this=0x7fffffffd860, startAgain=false, type=0) at
CbcModel.cpp:10949<br>
#10 0x00007ffff7b28f30 in CbcModel::branchAndBound
(this=0x7fffffffd860, doStatistics=0) at CbcModel.cpp:1920<br>
#11 0x0000000000403e4e in main (argc=1, argv=0x7fffffffde88)
at user_driver.cpp:328</font></small><br>
</blockquote>
on<br>
<blockquote>SMP x86_64 x86_64 x86_64 GNU/Linux<br>
g++ (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]<br>
compiled against 2.8 of the CBC library<br>
</blockquote>
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... <br>
<br>
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.<br>
<br>
Any help appreciated.<br>
<br>
Dirk<br>
<br>
<br>
</body>
</html>