Opened 7 years ago

Closed 8 months ago

#56 closed defect (migrated)

Segmentation fault when setting factorisation

Reported by: patra Owned by: somebody
Priority: major Milestone:
Component: component1 Version:
Keywords: Cc:

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.

Change History (2)

comment:1 Changed 4 years ago by ralacroix

ClpModel?.hpp lists possible values for problemStatus_. A value of 3 indicates that the solver stopped on iterations or time. In either case the user told the solver to quit early, so the interface should return a result gracefully rather than crash.

comment:2 Changed 8 months ago by stefan

  • Resolution set to migrated
  • Status changed from new to closed

This ticket has been migrated to GitHub and will be resolved there: ​https://github.com/coin-or/Clp/issues/56

Note: See TracTickets for help on using tickets.