Custom Query (86 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (31 - 33 of 86)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#56 migrated Segmentation fault when setting factorisation somebody patra
Description

One of my programs reproducibly crashes when asked to solve a large MIP optimisation problem for given parameters. I should add that this occurs rather infrequently, perhaps for about 1% of all tested input parameters for my model. The crash only happens after quite a few iteration steps have been done, usually more than 10000.

I use Clp as part of Cbc-2.7.6. The version used there is Clp-1.14.6, thus the current version of Clp.

This shows a backtrace of a segmentation fault that I've analysed:

#0  0x0000000000b61564 in ClpFactorization::operator= (this=0x16410d0, rhs=@0x0) at ClpFactorization.cpp:1293
#1  0x0000000000b61a0b in ClpFactorization::setFactorization (this=0x16410d0, rhs=@0x0) at ClpFactorization.cpp:2843
#2  0x0000000000be1d07 in ClpSimplex::setFactorization (this=0x14fe700, factorization=@0x0) at ClpSimplex.cpp:4502
#3  0x0000000000aacf5f in OsiClpSolverInterface::solveFromHotStart (this=0x12d3ae0) at OsiClpSolverInterface.cpp:2376
#4  0x00000000009a306e in CbcNode::chooseDynamicBranch (this=0x145e650, model=0x7fff3f843380, lastNode=0x1823990,
    numberPassesLeft=4) at CbcNode.cpp:2827
#5  0x000000000096b7a6 in CbcModel::chooseBranch (this=0x7fff3f843380, newNode=@0x7fff3f83fa78, numberPassesLeft=5,
    oldNode=0x1823990, cuts=@0x7fff3f83f020, resolved=@0x7fff3f83f077, lastws=0x1910b00, lowerBefore=0x1611fd0,
    upperBefore=0x152beb0, branches=@0x7fff3f83f068) at CbcModel.cpp:12647
#6  0x0000000000978a74 in CbcModel::doOneNode (this=0x7fff3f843380, baseModel=0x7fff3f843380, node=@0x7fff3f83fa00,
    newNode=@0x7fff3f83fa78) at CbcModel.cpp:14305
#7  0x0000000000994c14 in CbcModel::branchAndBound (this=0x7fff3f843380, doStatistics=0) at CbcModel.cpp:3800

In OsiClpSolverInterface::solveFromHotStart, the function setFactorization is called, with the internal variable OsiClpSolverInterface::factorization_ as its argument. Since that internal variable happens to be NULL, a segmentation fault occurs further down the calling sequence. The actual bug seems to be that OsiClpSolverInterface::factorization_ is equal to NULL - which it shouldn't be - and not the coding of ClpSimplex::setFactorization or the functions called by it.

I've traced the reason for OsiClpSolverInterface::factorization_ being NULL to OsiClpSolverInterface::markHotStart [see line 2077 of OsiClp/OsiClpSolverInterface?.cpp]. Since SETUP_HOT is defined by default, only the second part of the code is relevant. The segmentation fault that I have analysed occurs when factorization_==NULL and small->problemStatus_==3. This is why the assertion doesn't signal an error but OsiClpSolverInterface::factorization_ still is set to zero.

#ifndef SETUP_HOT
      assert (factorization_==NULL);
      factorization_ = static_cast<ClpSimplexDual *>(small)->setupForStrongBranching(spareArrays_,numberRows,
			     numberColumns,false);
#else
      assert (factorization!=NULL || small->problemStatus_ );
      factorization_ = factorization;
      /* This is where factorization_ is set to NULL while
         small->problemStatus_ == 3 */
#endif

Without really knowing what I'm doing, I've copied the initialisation statement from the first part of the #ifdef-statement to the second.

#ifndef SETUP_HOT
      assert (factorization_==NULL);
      factorization_ = static_cast<ClpSimplexDual *>(small)->setupForStrongBranching(spareArrays_,numberRows,
			     numberColumns,false);
#else
      assert (factorization!=NULL || small->problemStatus_ );
      factorization_ = factorization;
      if( factorization_ == NULL )
      factorization_ = static_cast<ClpSimplexDual *>(small)->setupForStrongBranching(spareArrays_,numberRows,
			     numberColumns,false);
#endif

And, to my surprise, it actually seems to cure the problem. The program no longer crashes, and the computed results are correct. Before this line of code is added as a bug fix to the repository, somebody who actually understands what that part of the code is supposed to do, should, of course, have a more in-depth look first.

#55 migrated ClpSolve::infeasibleReturn ignored somebody mlubin
Description

It seems that the ClpSolve::infeasibleReturn option is ignored when infeasibility is detected from tightening primal bounds. See the code below from trunk (ClpSolve?.cpp starting at line 915):

if (method == ClpSolve::useDual) {
          double * saveLower = NULL;
          double * saveUpper = NULL;
          if (presolve == ClpSolve::presolveOn) {
               int numberInfeasibilities = model2->tightenPrimalBounds(0.0, 0);
               if (numberInfeasibilities) {
                    handler_->message(CLP_INFEASIBLE, messages_)
                              << CoinMessageEol;
                    delete model2;
                    model2 = this;
                    presolve = ClpSolve::presolveOff;
               }
          } else if (numberRows_ + numberColumns_ > 5000) {
               // do anyway
               saveLower = new double[numberRows_+numberColumns_];
               CoinMemcpyN(model2->columnLower(), numberColumns_, saveLower);
               CoinMemcpyN(model2->rowLower(), numberRows_, saveLower + numberColumns_);
               saveUpper = new double[numberRows_+numberColumns_];
               CoinMemcpyN(model2->columnUpper(), numberColumns_, saveUpper);
               CoinMemcpyN(model2->rowUpper(), numberRows_, saveUpper + numberColumns_);
               int numberInfeasibilities = model2->tightenPrimalBounds();
               if (numberInfeasibilities) {
                    handler_->message(CLP_INFEASIBLE, messages_)
                              << CoinMessageEol;
                    CoinMemcpyN(saveLower, numberColumns_, model2->columnLower());
                    CoinMemcpyN(saveLower + numberColumns_, numberRows_, model2->rowLower());
                    delete [] saveLower;
                    saveLower = NULL;
                    CoinMemcpyN(saveUpper, numberColumns_, model2->columnUpper());
                    CoinMemcpyN(saveUpper + numberColumns_, numberRows_, model2->rowUpper());
                    delete [] saveUpper;
                    saveUpper = NULL;
               }
          }

At an earlier point in the same file (line 502), there is:

if (!model2) {
               handler_->message(CLP_INFEASIBLE, messages_)
                         << CoinMessageEol;
               model2 = this;
	       eventHandler()->event(ClpEventHandler::presolveInfeasible);
               problemStatus_ = pinfo->presolveStatus(); 
               if (options.infeasibleReturn() || (moreSpecialOptions_ & 1) != 0) {
		 delete pinfo;
                    return -1;
               }
               presolve = ClpSolve::presolveOff;
	  }

The code in the first snippet should include a check for options.infeasibleReturn() as in the second snippet.

#54 migrated HotStart problem with stable/1.14 somebody fmargot
Description

The attached code reads an LP file, initialSolve(), markHotStart(), change both bounds of variable 11 to 3, solveFromHotStart(), change both bounds of variable 11 to 2, solveFromHotStart().

When printing the status of the optimization, when bounds are 3, the problem is not solved to optimality and iterationLimit is reached, which is quite odd for such a small problem. If the input file is modified, setting the lower bound of var 11 to 3 in the lp file, the three problems are solved to optimality (they all have an optimal value of 49).

It also seems that getIterationCount() always returns 0 when using solveFromHotstart().

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.