[Cbc] "Index out of bounds" when pre-processing problems with SOSes

[Dirk Eßer]

Hello John,

sorry for not making the context clear. As I said in my original post, 
"setInteger" is exactly, what we are using to declare the integer 
columns. We once did it by adding "OsiSimpleInteger" instances, but 
changed that, when the problem first appeared after adding the 
pre-processing step.

What I found out in the mean time, though, is that there is indeed 
something the application does, which is not properly reflected in the 
user_driver.cpp: the application explicitly calls 
"OsiClpSolverInterface::findIntegersAndSOS(false)" on the initial solver 
instance, which we use to build the problem description. This happens 
right after all integer declarations (via setInteger) have been made, 
and all SOSs have been declared. I don't recall, when (and why) exactly 
I added that call, but it must have been at the time, we switched from 
"OsiSimpleInteger"-style declarations to "setInteger":

    ... matrix set-up, etc. ...

    if (num_integers > 0)
    {
         iptr.setInteger(&m_integers[0], num_integers);
    }

    if (num_sos > 0)
    {
         static const double weights[] = { 1.0, 2.0 };
         rowvec<OsiObject*> pobjs(num_sos);
         int members[2];
         int ix = 0;

         for (std::vector<int>::const_iterator it = m_sos.begin(); it !=
    m_sos.end(); )
         {
             members[0] = *it; ++it;
             members[1] = *it; ++it;
             pobjs[ix++] = new OsiSOS(&iptr, 2, members, weights, 1);
         }

         iptr.addObjects(ix, pobjs.begin());
         DEBUGOUT("Added " << ix << " SOS constraint(s)");

         delete_all(pobjs.begin(), pobjs.begin() + ix);
    }

    if (DO_EXPLICIT_FINDINT)
    {
         iptr.findIntegersAndSOS(false);
    }

If I leave the call in, the SOS code properly works (using your 
changes), but we trigger the "assert()" in 
"OsiSolverInterface::findIntegers":

    #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 0x00007ffff4ab79ed in OsiSolverInterface::findIntegers
    (this=0x7ff4e8, justCount=false) at OsiSolverInterface.cpp:1978
    #5 0x00007ffff426537c in OsiClpSolverInterface::deleteCols
    (this=0x7ff240, num=2, columnIndices=0x804d50) at
    OsiClpSolverInterface.cpp:3236
    #6 0x00007ffff510c436 in CbcModel::AddIntegers (this=0x7fffffff84f0)
    at CbcModel.cpp:1306
    #7 0x00007ffff5112812 in CbcModel::branchAndBound
    (this=0x7fffffff84f0, doStatistics=0) at CbcModel.cpp:2701
    #8 0x00007ffff53fb5e7 in lp::detail::(anonymous
    namespace)::solve_via_cbc (LP=...) at src/Expr_problem.cpp:674
    #9 0x00007ffff53fd893 in lp::detail::program_impl::solve_for
    (this=0x6be510, s=..., result=@0x7fffffff90b0: 0) at
    src/Expr_problem.cpp:1151

If I comment the call out, then the SOS fails with the "well-known" 
error, even in the presence of your changes:

    #0 0x00007ffff60f8849 in raise () from /lib64/libc.so.6
    #1  0x00007ffff60f9cd8 in abort () from /lib64/libc.so.6
    #2  0x00007ffff69f1655 in __gnu_cxx::__verbose_terminate_handler()
    () from /usr/lib64/libstdc++.so.6
    #3  0x00007ffff69ef7c6 in ?? () from /usr/lib64/libstdc++.so.6
    #4  0x00007ffff69ef7f3 in std::terminate() () from
    /usr/lib64/libstdc++.so.6
    #5  0x00007ffff69efa1e in __cxa_throw () from /usr/lib64/libstdc++.so.6
    #6  0x00007ffff4486185 in indexError (index=4,
    methodName="isInteger") at OsiClpSolverInterface.cpp:1447
    #7  0x00007ffff448c02f in OsiClpSolverInterface::isInteger
    (this=0x6d2c70, colNumber=4) at OsiClpSolverInterface.cpp:2756
    #8  0x00007ffff5395dd1 in CbcSOS::CbcSOS (this=0x6b2790,
    model=0x7fffffffc980, numberMembers=2, which=0x6cec00,
    weights=0x6ceb20, identifier=3, type=1) at CbcSOS.cpp:67
    #9  0x00007ffff535d267 in CbcModel::findIntegers
    (this=0x7fffffffc980, startAgain=false, type=0) at CbcModel.cpp:10966
    #10 0x00007ffff5337f30 in CbcModel::branchAndBound
    (this=0x7fffffffc980, doStatistics=0) at CbcModel.cpp:1920
    #11 0x00007ffff56245d9 in lp::detail::(anonymous
    namespace)::solve_via_cbc (LP=...) at src/Expr_problem.cpp:678
    #12 0x00007ffff5626bea in lp::detail::solution_impl::solve_lp
    (this=0x6b0e70, base=...) at src/Expr_problem.cpp:1660

What got me confused was, that those errors occur in different tests 
(i.e., when the one works, the other fails and vice versa).



Am 13.05.2014 16:44, schrieb John Forrest:
> Dirk,
>
> Using OsiSimpleInteger may be a bit heavyweight (and lead to 
> problems).  Why not just use setInteger?
>
> John
> _______________________________________________
> 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/cf562871/attachment-0001.html>