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

Mon Oct 22 14:36:47 EDT 2012

I confirm this bug - it also exists in the sequential version of CBC.

There is a simple way to reproduce it, using the last CBC revision   (1792).

Just run in instance   glass4   from miplib
http://miplib.zib.de/miplib2003/miplib2003/glass4.php

After 6000 nodes it crashes:

Cbc0010I After 6000 nodes, 2633 on tree, 1.9500178e+09 best solution, best
possible 8.0000498e+08 (64.08 seconds)
Cbc0038I Full problem 392 rows 317 columns, reduced to 311 rows 67 columns
- too large
cbc: CbcSOS.cpp:303: virtual double CbcSOS::infeasibility(const
OsiBranchingInformation*, int&) const: Assertion `pi[iRow] >= -1.0e-3'
failed.

On Mon, Oct 22, 2012 at 4:14 PM, vladimir voloshinov <
vladimir.voloshinov at gmail.com> wrote:

> 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
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc
>

-- 
=============================================================
Haroldo Gambini Santos
Computing Department - Universidade Federal de Ouro Preto - UFOP
email: haroldo [at ] iceb.ufop.br
home/research page: www.decom.ufop.br/haroldo/

"Computer science is no more about computers than astronomy
is about telescopes." Edsger Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20121022/22e5720a/attachment.html>