[Clp] OsiClp causes crash when deleting OsiCLPSolverInterface. Reason: borrowModel?

[Torsten Fahle]

Hi there,

we found a problem with some large LP-Model that is transferred to CLP via Osi-Interface.
The problems occurs with Clp, Osi, Coin from the CBC 2.1.0 distribution.

We use an OsiClpSolverInterface, create a model and solve it via initialSolve.

During initialSolve, some memory allocation fails and a bad_alloc exception is
thrown which we catch in our application. 
At that moment, however, our OsiClpSolverInterface object is corrupt so that calling delete on that
object causes an "Access vialotaion" followed by an application crash.


     OsiClpSolveInterface mySolver = new OsiClpSolverInterface;
     [...]

     [generate CoinModel myModel]

     mySolver->loadFromCoinModel(myModel);

     try {
        mySolver->initialSolve();
     }
     catch (bad_alloc)
    {
        cout << "Bad Alloc" << endl;
    }
    [...]
   delete mySolver;  // <<<==== ACCESS VIOLATION, because ModelPtr->clpMatrix is invalid


After some deeper look into what's happening the reason seems to be the 
borrwoModel/returnModel mechanism:

The OsiClpSolverInterface holds a modelPtr can contains (among others) our clp-matrix.

When calling OsiClpSolverInterface->initialSolve()  [OsiClpSolverInterface.cpp, l. 48]
a ClpSimplex object named solver is created  [OsiClpSolverInterface.cpp, l. 50]
that borrows the modelPtr [OsiClpSolverInterface.cpp, l. 52].

In [OsiClpSolverInterface.cpp, l. 162]  ClpPresolve is prepared and called.
During that call, presolve fails to allocate memory in  [CoinPresolveImpliedFree.cpp, l. 521], 
called from [ClpPresolve.cpp 546].

Now, a bad_alloc exception is thrown and all objects on the call stack are destroyed up to the 
 try/catch block in our application. During that unwinding and cleaning, also the borrowed modelPtr
is deleted although not owned by solver. 
Because the ecxeption causes an immediate unrolling of the call stack "returnModel" is not called.

When our application later on tries to delete the correctly allocated OsiClpSolverInterface, the destructor 
tries to delete the modelPtr and that causes the "access violation" described above.

Question: 
Would it be possible to make the borrowModel/returnModel mechanism more robust?
E.g. borrowModel could also set a bool indicating that the model is only borrowed, and a destructor
triggered e.g. by the  exception cleanup could check first whether that model is owned or borrowed.

Thanks

 Torsten





-- 

Dr. Torsten Fahle
Airport Systems Division
INFORM GmbH, Pascalstr.23, 52076 Aachen, Germany
Tel. (+49) 24 08 - 94 56 3024  FAX: -94 56 25
e-mail: Torsten.Fahle at inform-ac.com   http://www.groundstar.de 
INFORM Institut fuer Operations Research und Management GmbH
Registered AmtsG Aachen HRB1144 Gfhr.Adrian Weiler