<font size=2 face="sans-serif">It's probable that the debug version is
imposing some constraint on thread-switching that</font>
<br><font size=2 face="sans-serif">prevents the problem from occurring.</font>
<br>
<br><font size=2 face="sans-serif">I ran the problem over the weekend with
no -threads option (I think this is equivalent to</font>
<br><font size=2 face="sans-serif">-threads 0, right?), and indeed, when
I came in this morning it had happily chugged through</font>
<br><font size=2 face="sans-serif">40 million nodes without faulting. So
all the experimental evidence points to a concurrency</font>
<br><font size=2 face="sans-serif">bug.</font>
<br>
<br><font size=2 face="sans-serif">For now I will use -threads 104 and
take the mild performance hit, but we will be waiting</font>
<br><font size=2 face="sans-serif">eagerly for your "trivial feature";
a factor of several thousand speedup sounds lovely!</font>
<br>
<br><font size=2 face="sans-serif">Thank you very much for your efforts.</font>
<br>
<br><font size=2 face="sans-serif">Allan Wechsler</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">John Forrest <john.forrest@fastercoin.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">acw@ascent.com</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">cbc@list.coin-or.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">03/11/2013 04:44 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Cbc] Cbc segfault after many hours
of CPU time</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Status report on segfault.<br>
<br>
Unable to reproduce with debug version.<br>
<br>
Have reproduced segfaults three times with optimized version. It
is <br>
always to do with multi-threading. Once I could see something I didn't
<br>
like so have modified that. However the other two times it was not
<br>
obvious. Looking at registers and disassembled code I could see <br>
segfault but going from a few instructions back it should have worked.
<br>
So classic overwriting due to threads. But I can't see what is wrong
<br>
with locking/unlocking threads to stop overwriting. Will continue <br>
looking slowly.<br>
<br>
However if you use -thread 104 instead of 4 that switches on <br>
deterministic parallel. This is not quite as efficient (it would
be a <br>
lot better if the effort per node was better determined e.g. as in <br>
Cplex's"ticks") but does not have same problem. That has
been running a <br>
long time without a problem (>63 million nodes).<br>
<br>
Using my (not in svn yet) trunk and throwing every cut at problem I can
<br>
prove solution of 499243.8 is optimal after 23 million nodes.<br>
<br>
However looking at problem I tried another trivial experimental feature
<br>
on problem. There may be bugs, but I don't think so. That took
15,368 <br>
nodes and 54 seconds.<br>
<br>
John Forrest<br>
</font></tt>
<br>