[Cbc] Segmentation fault in release build revealed assertion failed in debug build

[vladimir voloshinov]

Dear Сbc team,
can you help with the following problem.
=====================
Short description:
A few days ago, I compiled and installed OS package (on Linux Ubuntu 12.*)
(from svn co https://projects.coin-or.org/svn/OS/releases/2.6.0 and
I replaced COIN-OS/Cbc with Cbc 2.7,7 "manually").

We have a MILP problem which causes multi-threaded running of Cbc
(with more than 4 threads, release build without debugging symbols) to
throw "Segmentation fault" after long run period (hundred of thousands
nodes) in CbcModel::addCuts1(...)
/* $Id: CbcModel.cpp 1783 2012-06-06 13:33:48Z stefan $ */).
But on running debug build of the same COIN-OS at the same problem
caused "Assertion failed" in
CbcSOS.cpp:303: virtual double CbcSOS::infeasibility() ...
Assertion `pi[iRow] >= -1.0e-3' failed.
So, two questions:
1. Are there any recommendation to set compilation or running options
to avoid segmentation fault for multi-threaded Cbc running?
2. What about that mysterious problem with assertion in CbcSOS.cpp ?
(It looks like a check of dual variables sign, but why with double
const ?!)
=====================

Detailed  description.
We are working with some job-shop schedule problem formulated as a
MILP. After some experiments with LP_SOLVE (it works too long) and
Glpk (much faster) I decided to use COIN Cbc as MILP solver.
"make" and "make test" finished OK.

It was everything ok until I tried to solve some MILP problem (AMPL
stub file is uploaded to
http://dcs.isa.ru/~vladimirv/coin-or/cbc/w6_t30_shuffledDyn.nl).
It become a hard one and I tried to run Cbc with multiple-threads
(COIN-OS/configure had been run with --enable-cbc-parallel).
After a number of running
./OSSolverService  -nl w6_t30_shuffledDyn.nl -osol cbc.osol
(a number of threads has been set in <solverOption name="threads"
solver="cbc" value="nnn" /> tag of cbc.osol, uploaded to
http://dcs.isa.ru/~vladimirv/coin-or/cbc/cbc.osol)
I got "Segmentation fault" error for 4, 6, 8 threads,
(2-threaded sample is still running), it is worth to mention that the SIGSEGV
signal appeared after long run period (after check of hundred thousands and
even million B&B tree nodes).
When I tried to detect source of error by gdb:
gdb --args ./OSSolverService  -nl w6_t30_shuffledDyn.nl -osol cbc.osol
I've got (see the end of sysout,  after  ~40000 nodes ):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5e93700 (LWP 22249)]
0x0000000000796a63 in CbcModel::addCuts1(CbcNode*, CoinWarmStartBasis*&) ()
(gdb) bt
#0  0x0000000000796a63 in CbcModel::addCuts1(CbcNode*, CoinWarmStartBasis*&) ()
#1  0x0000000000796ea2 in CbcModel::addCuts(CbcNode*,
CoinWarmStartBasis*&, bool) ()
#2  0x00000000007a46fa in CbcModel::doOneNode(CbcModel*, CbcNode*&,
CbcNode*&) ()
#3  0x00000000007c1c1a in doNodesThread(void*) ()
#4  0x00007ffff79bce9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff69bedbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

To get more info I compiled debug build:
./configure --prefix=/home/vladimirv/coin-or/COIN-OS/build.debug
--disable-shared --enable-cbc-parallel --enable-debug
"make" and "make test" finished OK.

BUT, after that, the run of single thread debug version permanently
throws another
[New Thread 0x7ffff6694700 (LWP 4629)]
Cbc0010I After 0 nodes, 1 on tree, 17.666667 best solution, best
possible 5.5506109 (5.32 seconds)
Cbc0038I Full problem 2664 rows 210 columns, reduced to 2083 rows 93
columns - too large
OSSolverService: CbcSOS.cpp:303: virtual double
CbcSOS::infeasibility(const OsiBranchingInformation*, int&) const:
Assertion `pi[iRow] >= -1.0e-3' failed.

The further check revealed that "suspicious" pi[iRow] is about -0.005. ??!!

Sincerely yours,
--
Vladimir V. Voloshinov,
Ph.D, head of lab. C-3 "Distributed computing algorithms"
Center of Grid-technologies & Distributed Computing, http://dcs.isa.ru,
web: http://dcs.isa.ru/drupal/ru/staff/vladimirv