[Clp] ClpModel subproblem constructor accesses illegal elements in rhs->ray_

[John Forrest]

Valentin,

The problem is not actually in Clp 1.11 but in Osi.  I have made fixes
to Osi/trunk, Osi/stable/0.101 and Osi/stable/0.102.

There seems to be some mismatch in the use of Osi.  Cbc/trunk uses
Osi/0.101 while Cbc/stable/2.4 uses Osi/0.102 which seems slightly odd.

John Forrest
On Tue, 2010-02-23 at 17:54 +0100, Valentin Ziegler wrote:
> Hello,
> 
> I encountered an issue with Clp 1.11.0. The subproblem ctor
> 
> 	ClpModel::ClpModel ( const ClpModel * rhs,
> 					int numberRows, const int *
> whichRow,
> 					int numberColumns, const int *
> whichColumn
> 					....
> 
> copies selected elements from rhs->ray_. Depending on the problem
> status,
> the superproblem's ray_ is interpreted as a column indexed or row
> indexed vector:
> 
> 	....
> 	if (problemStatus_==1)
> 		ray_ = whichDouble (rhs->ray_,numberRows,whichRow);
> 	else if (problemStatus_==2)
> 		ray_ = whichDouble
> (rhs->ray_,numberColumns,whichColumn);
> 	....
> 
> However, it is possible that the superproblem's ray is still allocated
> as a column
> indexed array even though problemStatus==1. Consider following scenario:
> 
> - setupForRepeatedUse(2)
> - create a dual infeasible LP with more rows than columns
> - initialSolve
> - modify row bounds so LP becomes primal infeasible
> - resolve
> - resolve again --> crash
> 
> Here, the first resolve creates a subproblem in
> OsiClpSolverInterface::crunch().
> Then, primal infeasibility is detected within that subproblem and the
> subproblem's ray
> is reallocated to hold a row indexed array. The superproblem's ray is
> untouched and still
> points to the column indexed array created by
> ClpSimplexPrimal::primalRay(CoinIndexedVector * rowArray).
> 
> When the second resolve creates a new subproblem (problemStatus_ now
> changed from 2 to 1),
> the ClpModel ctor expects to find a row indexed vector in rhs->ray_ (see
> above) and will
> read over array bounds which occasionally leads to a crash.
> 
> With crunching disabled (special option 2048), the problem seems to
> disappear.
> Is there any chance to fix this (except for 2048) ? This would be a
> great help to me.
> 
> Attached is a small code snipplet that triggers the problem described
> above.
> 
> Many thanks
> Valentin
> 
> 
> 
> --
> Valentin Ziegler . vziegler at think-cell.com
> Software Engineer
>  
> think-cell Software GmbH . Chausseestr. 8/E . 10115 Berlin, Germany 
> http://www.think-cell.com . phone +49 30 666473-10 . toll-free (US) +1 800 891 8091
> Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl . Amtsgericht Berlin-Charlottenburg, HRB 85229
> 
> _______________________________________________
> Clp mailing list
> Clp at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/clp