<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hello John,<br>
<br>
the changes work fine, the problem with SOS is gone now, thank you
very much.<br>
<br>
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):<br>
<blockquote><small><font face="Courier New, Courier, monospace">#0
0x00007ffff60f8849 in raise () from /lib64/libc.so.6</font></small><br>
<small><font face="Courier New, Courier, monospace">#1
0x00007ffff60f9cd8 in abort () from /lib64/libc.so.6</font></small><br>
<small><font face="Courier New, Courier, monospace">#2
0x00007ffff60f1616 in __assert_fail_base () from
/lib64/libc.so.6</font></small><br>
<small><font face="Courier New, Courier, monospace">#3
0x00007ffff60f16c2 in __assert_fail () from /lib64/libc.so.6</font></small><br>
<small><font face="Courier New, Courier, monospace">#4
0x00007ffff4ce09ed in OsiSolverInterface::findIntegers
(this=0x7d9798, justCount=false) at
OsiSolverInterface.cpp:1978</font></small><br>
<small><font face="Courier New, Courier, monospace">#5
0x00007ffff448e37c in OsiClpSolverInterface::deleteCols
(this=0x7d94f0, num=2, columnIndices=0x7d3f30) at
OsiClpSolverInterface.cpp:3236</font></small><br>
<small><font face="Courier New, Courier, monospace">#6
0x00007ffff5335436 in CbcModel::AddIntegers
(this=0x7fffffffc980) at CbcModel.cpp:1306</font></small><br>
<small><font face="Courier New, Courier, monospace">#7
0x00007ffff533b812 in CbcModel::branchAndBound
(this=0x7fffffffc980, doStatistics=0) at CbcModel.cpp:2701</font></small><br>
<small><font face="Courier New, Courier, monospace">#8
0x00007ffff5625a87 in lp::detail::(anonymous
namespace)::solve_via_cbc (LP=...) at src/Expr_problem.cpp:674</font></small><br>
<small><font face="Courier New, Courier, monospace">(gdb) fr 4 <br>
#4 0x00007ffff4ce09ed in OsiSolverInterface::findIntegers
(this=0x7d9798, justCount=false) at
OsiSolverInterface.cpp:1978<br>
1978 assert
(iColumn>=0&&iColumn<numberColumns);<br>
(gdb) l<br>
1973 for (iObject = 0;iObject<nObjects;iObject++) {<br>
1974 OsiSimpleInteger * obj =<br>
1975 dynamic_cast <OsiSimpleInteger
*>(oldObject[iObject]) ;<br>
1976 if (obj) {<br>
1977 iColumn = obj->columnNumber();<br>
1978 assert
(iColumn>=0&&iColumn<numberColumns);<br>
1979 marked[iColumn]=iObject;<br>
1980 }<br>
1981 }<br>
1982 // make a large enough array for new objects</font></small><br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 13.05.2014 14:25, schrieb John
Forrest:<br>
</div>
<blockquote cite="mid:53720F3D.5060208@fastercoin.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Dirk,<br>
<br>
SOS with pre-processing is a bit delicate - I attach a modified
driver which resets the SOS indices after preprocessing.<br>
<br>
I used a const_cast which is a bit naughty (but safe).<br>
<br>
John<br>
On 13/05/14 09:17, Dirk Eßer wrote:<br>
</div>
<blockquote cite="mid:5371D4FD.9060405@web.de" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
</body>
</html>