[Coin-symphony] SPP+CUTS

[Michael Hennebry]

I've trying to use spp in SPP+CUTS to solve a set partioning problem.
It rather reliably core dumps in line 286 of CglOddHole.cpp.
Before that in prints some interestig things.

Things like this:
Violated ODD HOLE inequality found
   Indices (names): 802 (1884)  939 (1747)  2459 (227)  2324 (362)  2187 (499)
   type: 1,  num: 5, rhs: 2.000000,  violation: 0.249220
CG: Number of cuts in cut_coll: 120
    Type and multiplicity of cuts:    [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [0, 0]   [1, 0]   [1, 0]   [1, 0]   [1, 0]   [1, 2]   [1, 2]   [1, 0]

valgrind follows it with
==8041==
==8041== Use of uninitialised value of size 8
==8041==    at 0x1B9A4A96: CoinFactorization::pivotOneOtherRow(int, int) (CoinFactorization1.cpp:1945)
==8041==    by 0x3FB99998: ???
==8041==
==8041== Use of uninitialised value of size 8
==8041==    at 0x1B9A4B8D: CoinFactorization::pivotOneOtherRow(int, int) (CoinFactorization1.cpp:2010)
==8041==    by 0x3FB99998: ???
==8041==
==8041== Conditional jump or move depends on uninitialised value(s)
==8041==    at 0x1B94914F: check_row_effectiveness(LP_PROB*) (lp_rowfunc.c:184)
==8041==    by 0x1B94A16F: fathom_branch(LP_PROB*) (in /disk2/people/hennebry/cointop/COIN/SYMPHONY/lib/LINUX/APPL_OSI_CLP/libsym_app_m_tm_lp_cg_cp.so)
==8041==    by 0x1B949D77: process_chain(LP_PROB*) (in /disk2/people/hennebry/cointop/COIN/SYMPHONY/lib/LINUX/APPL_OSI_CLP/libsym_app_m_tm_lp_cg_cp.so)
==8041==    by 0x1B93C648: solve(TM_PROB*) (in /disk2/people/hennebry/cointop/COIN/SYMPHONY/lib/LINUX/APPL_OSI_CLP/libsym_app_m_tm_lp_cg_cp.so)

There is one more such display.
It has no "[1, 2]"s.  All types and multiplicities are 0.

There are several more display with "[0, 0]"s,
but no conditional jumps of note.

Despite the oddness of these displays,
they appear unrelated to the core dumps.

Line 286:
           cost[n]=cost[k];

According to gdb, cost[n] does not exist, but cost[k] does.
n=26111, k=507.
*suitableRow does not exist.  suitableRow is not null.
*fixedColumn=-1.


-- 
Mike   hennebry at web.cs.ndsu.NoDak.edu
"Our gods are dead.  Ancient Klingon warriors slew them
... they were more trouble than they were worth."          --  Worf