[Clp] problem with initialSolve()

[Kish Shen]

Hi,

I have recently updated the Clp/Cbc solver I use to a recent trunk 
branch version, thanks to the help of John Forrest. After checking that 
everything is working on the Linux platform, I built the system for the 
other platforms we distribute the binaries for. On the Windows version, 
I am now getting a segmentation fault, apparently for about 50% of the 
runs, for one test in our test suite. The seg fault does not occur on 
the Linux platform, nor with the older (downloaded Nov 2007) Clp/Cbc 
solver I was using previously.

The problematic test sets up a simple problem, and then changes the 
objective function before solving it, and then the objective function is 
changed again and resolved. The seg fault seem to happen with the first 
solve.

As we build the Windows system using a MinGW cross-compiler on Linux, 
which is not the standard way of building Clp/Cbc for Windows, it may be 
difficult to reproduce the problem, so I decided to run valgrid with the 
test on our Linux (32 bit x86) build. Although there is no seg fault 
with this, valgrind does return some errors when initialSolve() (from 
OsiClpSolverInterface) is called:

[eclipse 3]: probeexample.
==12317== Invalid read of size 8
==12317==    at 0x4CE0DF3: 
CoinPrePostsolveMatrix::setColumnStatusUsingValue(int) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==  Address 0x4328b98 is 0 bytes after a block of size 24 alloc'd
==12317==    at 0x401A951: malloc (vg_replace_malloc.c:207)
==12317==    by 0x4D63B97: operator new(unsigned) (new_op.cc:57)
==12317==    by 0x4D63C3C: operator new[](unsigned) (new_opv.cc:37)
==12317==    by 0x4B50F6F: CoinPresolveMatrix::CoinPresolveMatrix(int, 
double, ClpSimplex*, int, int, bool, double, double) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==    by 0x4B524E8: 
ClpPresolve::gutsOfPresolvedModel(ClpSimplex*, double, bool, int, bool, 
bool) (in /user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==    by 0x4A8ECC3: OsiClpSolverInterface::initialSolve() (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==    by 0x4A791AD: coin_solveLinear(lp_desc*, int, int) 
(coinplex.cpp:581)
==12317==    by 0x4A7A55D: coin_solve_problem (coinplex.cpp:1537)
==12317==    by 0x4A7109D: p_cpx_optimise (seplex.c:6122)
==12317==    by 0x40768B9: ec_emulate (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/libeclipse.so)
==12317==
==12317== Invalid read of size 8
==12317==    at 0x4CE0DF9: 
CoinPrePostsolveMatrix::setColumnStatusUsingValue(int) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==  Address 0x4324a10 is 0 bytes after a block of size 24 alloc'd
==12317==    at 0x401A951: malloc (vg_replace_malloc.c:207)
==12317==    by 0x4D63B97: operator new(unsigned) (new_op.cc:57)
==12317==    by 0x4D63C3C: operator new[](unsigned) (new_opv.cc:37)
==12317==    by 0x4B4F730: 
CoinPrePostsolveMatrix::CoinPrePostsolveMatrix(ClpSimplex const*, int, 
int, int, double) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==    by 0x0: ???
==12317==
==12317== Invalid read of size 8
==12317==    at 0x4CE0DFF: 
CoinPrePostsolveMatrix::setColumnStatusUsingValue(int) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==  Address 0x4324a58 is 0 bytes after a block of size 24 alloc'd
==12317==    at 0x401A951: malloc (vg_replace_malloc.c:207)
==12317==    by 0x4D63B97: operator new(unsigned) (new_op.cc:57)
==12317==    by 0x4D63C3C: operator new[](unsigned) (new_opv.cc:37)
==12317==    by 0x4B4F73B: 
CoinPrePostsolveMatrix::CoinPrePostsolveMatrix(ClpSimplex const*, int, 
int, int, double) (in 
/user/eclipse/Eclipse_6.0_41/lib/i386_linux/seosiclpcbc.so)
==12317==    by 0x0: ???


I don't get these messages from valgrind when I run the test with the 
older CLP/CBC I have been using.

The seg fault with the Windows version also seem to occur when the same 
initialSolve() is called, but I do not know for certain that the above 
problem detected by valgrind is the cause. Does the above look like a 
real problem in Cbc? If so, I can send the code that will generate the 
above messages (although I cannot get this to reproduce the seg fault).

Thanks and cheers,

Kish


-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.