Re: [Computer-go] Strange GNU Go ladder behavior
I haven't been able to reproduce it in isolation yet (including by replaying from an SGF), but when I run several hundred games, this consistently happens in several of them. On Thu, Jun 18, 2015 at 3:57 PM, René van de Veerdonk rene.vandeveerd...@gmail.com wrote: Can you reproduce it issuing gtp commands, i.e., loading in the failing position from sgf-file and requesting gnugo to generate a move? Example: loadsgf games/strategy25.sgf 61 gg_genmove black On Thu, Jun 18, 2015 at 3:56 PM, Petr Baudis pa...@ucw.cz wrote: Hi! I've observed the same thing when playtesting Pachi against GNUGo, since very long ago. If you look a few moves back, you will see GNUGo already taking progressively longer time as the ladder is played out. IMHO there's some crazy exptime backtrack that gets out of hand at some point. It'd be interesting to see if giving GNUGo some time limit helps. On Thu, Jun 18, 2015 at 03:45:18PM -0700, Peter Drake wrote: Nope, we're still getting these crashes with more memory in the system. It still looks like it's always GNU Go that's crashing, and it always happens some way into a ladder that Orego shouldn't really be playing out. On Thu, Jun 18, 2015 at 3:24 PM, Peter Drake dr...@lclark.edu wrote: I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
I applied both of those patches to 3.8 (the stable version on http://www.gnu.org/software/gnugo/), but the problem has not gone away. Is there a more stable version? I finally found a file that causes the problem (attached). Specifically: [drake@broadcast ~]$ gnugo --infile results/2015/06/19/03:21:15.950/instance17-b1-2015-06-19-03:21:31.287.sgf Segmentation fault [drake@broadcast ~]$ gnugo --infile results/2015/06/19/03:21:15.950/instance17-b1-2015-06-19-03:21:31.287.sgf --until 10 white (O) move R16 This seems to work fine on GNU Go installed on some different machines. What to do? On Thu, Jun 18, 2015 at 4:11 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote: 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Could you reproduce that? Do you have sgf? GNU Go has some troubles in some compiler and OS. e.g. GNU Go 3.9.1. gcc 4.1.2, Debian 4.1.1-21, 32bit stops following sgf. I use own patch for GNU Go 3.7.10. http://computer-go.org/pipermail/computer-go/2010-November/001813.html And insert if ( eye_size = MAXEYE-2 ) break; in optics.c, line 1234. /* Create list of eye vertices */ for (pos2 = BOARDMIN; pos2 BOARDMAX; pos2++) { if ( eye_size = MAXEYE-2 ) break; if (!ON_BOARD(pos2)) Regards, Hiroshi Yamashita - (;GM[1]SZ[19] PB[Aya 7.04b] PW[GNU Go 3.7.10] DT[2010-11-22] RE[W+6.5]KM[6.5]TM[]RU[Chinese]PC[]EV[]GN[]AP[Aya 7.83g] ;B[qd];W[dd];B[dp];W[oc];B[pq];W[po];B[ld];W[qq];B[pc];W[pr] ;B[qm];W[cn];B[fq];W[bp];B[cq];W[ck];B[dl];W[en];B[fc];W[fe] ;B[cl];W[dk];B[ek];W[bq];B[bl];W[om];B[pk];W[cr];B[ee];W[ed] ;B[fd];W[ef];B[ge];W[de];B[fg];W[dh];B[dj];W[cj];B[ci];W[di] ;B[bj];W[ej];B[ch];W[bk];B[bi];W[ak];B[fo];W[fk];B[nk];W[eb] ;B[ec];W[db];B[dc];W[cc];B[el];W[fm];B[ho];W[fb];B[dg];W[eg] ;B[oq];W[gd];B[gc];W[hd];B[od];W[or];B[qp];W[pp];B[qr];W[rq] ;B[nr];W[nq];B[mq];W[np];B[hc];W[ic];B[id];W[he];B[ib];W[jc] ;B[hf];W[ie];B[if];W[je];B[mr];W[jf];B[lf];W[mp];B[kp];W[ig] ;B[hb];W[jb];B[lh];W[sn];B[hm];W[fl];B[mm];W[rl];B[ql];W[rj] ;B[rk];W[fs];B[os];W[op];B[lp];W[sk];B[qk];W[rh];B[ph];W[sl] ;B[hk];W[ji];B[hi];W[qf];B[hg];W[ih];B[hh];W[lj];B[kj];W[nj] ;B[ki];W[mk];B[nl];W[of];B[ff];W[gf];B[aj];W[cf];B[fj];W[cg] ;B[dr];W[br];B[co];W[bo];B[dn];W[dm];B[do];W[em];B[cm];W[bn] ;B[al];W[dj];B[nc];W[ds];B[qg];W[rg];B[qi];W[pf];B[ri];W[si] ;B[re];W[rf];B[qj];W[sj];B[gr];W[fh];B[gj];W[gs];B[gg];W[hr] ;B[rn];W[ro];B[qo];W[rp];B[so];W[ps];B[sm];W[sf];B[ge];W[ee] ;B[qn];W[jj];B[kk];W[gn];B[go];W[kg];B[lg];W[jr];B[er];W[es] ;B[iq];W[lb];B[hq];W[ir];B[kr];W[fi];B[mb];W[nm];B[ml];W[mo] ;B[nn];W[on];B[mn];W[lo];B[kn];W[jq];B[jp];W[ks];B[gm];W[kq] ;B[ls];W[lq];B[lr];W[fr];B[gq];W[hs];B[cp];W[eo];B[ep];W[jk] ;B[bg];W[ah];B[la];W[ka];B[kd];W[jl];B[jd];W[ma];B[kc];W[nb] ;B[mc];W[kb];B[gf];W[pb];B[ob];W[oa];B[qb];W[oc];B[eh];W[ei] ;B[ii];W[jg];B[bf];W[be];B[bc];W[bb];B[cd];W[cb];B[bd];W[ce] ;B[ob];W[rd];B[qe];W[oc];B[ia];W[pa];B[qa];W[jn];B[fn];W[am] ;B[jo];W[in];B[hn];W[sp];B[io];W[km];B[lk];W[ni];B[lm];W[mj] ;B[gb];W[ga];B[nh];W[ln];B[lc];W[la];B[fa];W[ea];B[im];W[jm] ;B[ko];W[sn];B[sh];W[gl];B[hl];W[bm];B[ob]) - ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ crashes-gnugo.sgf Description: Binary data ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
Nope, we're still getting these crashes with more memory in the system. It still looks like it's always GNU Go that's crashing, and it always happens some way into a ladder that Orego shouldn't really be playing out. On Thu, Jun 18, 2015 at 3:24 PM, Peter Drake dr...@lclark.edu wrote: I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
Hi! I've observed the same thing when playtesting Pachi against GNUGo, since very long ago. If you look a few moves back, you will see GNUGo already taking progressively longer time as the ladder is played out. IMHO there's some crazy exptime backtrack that gets out of hand at some point. It'd be interesting to see if giving GNUGo some time limit helps. On Thu, Jun 18, 2015 at 03:45:18PM -0700, Peter Drake wrote: Nope, we're still getting these crashes with more memory in the system. It still looks like it's always GNU Go that's crashing, and it always happens some way into a ladder that Orego shouldn't really be playing out. On Thu, Jun 18, 2015 at 3:24 PM, Peter Drake dr...@lclark.edu wrote: I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
Can you reproduce it issuing gtp commands, i.e., loading in the failing position from sgf-file and requesting gnugo to generate a move? Example: loadsgf games/strategy25.sgf 61 gg_genmove black On Thu, Jun 18, 2015 at 3:56 PM, Petr Baudis pa...@ucw.cz wrote: Hi! I've observed the same thing when playtesting Pachi against GNUGo, since very long ago. If you look a few moves back, you will see GNUGo already taking progressively longer time as the ladder is played out. IMHO there's some crazy exptime backtrack that gets out of hand at some point. It'd be interesting to see if giving GNUGo some time limit helps. On Thu, Jun 18, 2015 at 03:45:18PM -0700, Peter Drake wrote: Nope, we're still getting these crashes with more memory in the system. It still looks like it's always GNU Go that's crashing, and it always happens some way into a ladder that Orego shouldn't really be playing out. On Thu, Jun 18, 2015 at 3:24 PM, Peter Drake dr...@lclark.edu wrote: I have no idea what GNU Go does for memory management, but that does offer up a possibility: maybe the machine in question (a Google Compute Engine instance) is running out of memory. I've been using the highcpu machine types; I'll try a standard one (which has more memory) and see if the same thing happens. On Thu, Jun 18, 2015 at 1:41 PM, uurtamo . uurt...@gmail.com wrote: What does it do for memory management? Is it ungracefully failing while evaluating the ladder itself due to ram issues? steve On Jun 18, 2015 12:15 PM, Peter Drake dr...@lclark.edu wrote: This list may not be able to help, but I'm running out of clues on this one. I'm trying to run an experiment playing Orego against GNU Go in many games. Some of the games don't end properly. As far as I can tell, here's what happens: 1) Orego plays out a losing ladder. (That needs to be fixed, but that's another problem.) 2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Has anyone else encountered this? -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ -- Peter Drake https://sites.google.com/a/lclark.edu/drake/ ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go -- Petr Baudis If you have good ideas, good data and fast computers, you can do almost anything. -- Geoffrey Hinton ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
Re: [Computer-go] Strange GNU Go ladder behavior
2) At some point in the ladder, GNU Go quietly dies without responding to the move request. Could you reproduce that? Do you have sgf? GNU Go has some troubles in some compiler and OS. e.g. GNU Go 3.9.1. gcc 4.1.2, Debian 4.1.1-21, 32bit stops following sgf. I use own patch for GNU Go 3.7.10. http://computer-go.org/pipermail/computer-go/2010-November/001813.html And insert if ( eye_size = MAXEYE-2 ) break; in optics.c, line 1234. /* Create list of eye vertices */ for (pos2 = BOARDMIN; pos2 BOARDMAX; pos2++) { if ( eye_size = MAXEYE-2 ) break; if (!ON_BOARD(pos2)) Regards, Hiroshi Yamashita - (;GM[1]SZ[19] PB[Aya 7.04b] PW[GNU Go 3.7.10] DT[2010-11-22] RE[W+6.5]KM[6.5]TM[]RU[Chinese]PC[]EV[]GN[]AP[Aya 7.83g] ;B[qd];W[dd];B[dp];W[oc];B[pq];W[po];B[ld];W[qq];B[pc];W[pr] ;B[qm];W[cn];B[fq];W[bp];B[cq];W[ck];B[dl];W[en];B[fc];W[fe] ;B[cl];W[dk];B[ek];W[bq];B[bl];W[om];B[pk];W[cr];B[ee];W[ed] ;B[fd];W[ef];B[ge];W[de];B[fg];W[dh];B[dj];W[cj];B[ci];W[di] ;B[bj];W[ej];B[ch];W[bk];B[bi];W[ak];B[fo];W[fk];B[nk];W[eb] ;B[ec];W[db];B[dc];W[cc];B[el];W[fm];B[ho];W[fb];B[dg];W[eg] ;B[oq];W[gd];B[gc];W[hd];B[od];W[or];B[qp];W[pp];B[qr];W[rq] ;B[nr];W[nq];B[mq];W[np];B[hc];W[ic];B[id];W[he];B[ib];W[jc] ;B[hf];W[ie];B[if];W[je];B[mr];W[jf];B[lf];W[mp];B[kp];W[ig] ;B[hb];W[jb];B[lh];W[sn];B[hm];W[fl];B[mm];W[rl];B[ql];W[rj] ;B[rk];W[fs];B[os];W[op];B[lp];W[sk];B[qk];W[rh];B[ph];W[sl] ;B[hk];W[ji];B[hi];W[qf];B[hg];W[ih];B[hh];W[lj];B[kj];W[nj] ;B[ki];W[mk];B[nl];W[of];B[ff];W[gf];B[aj];W[cf];B[fj];W[cg] ;B[dr];W[br];B[co];W[bo];B[dn];W[dm];B[do];W[em];B[cm];W[bn] ;B[al];W[dj];B[nc];W[ds];B[qg];W[rg];B[qi];W[pf];B[ri];W[si] ;B[re];W[rf];B[qj];W[sj];B[gr];W[fh];B[gj];W[gs];B[gg];W[hr] ;B[rn];W[ro];B[qo];W[rp];B[so];W[ps];B[sm];W[sf];B[ge];W[ee] ;B[qn];W[jj];B[kk];W[gn];B[go];W[kg];B[lg];W[jr];B[er];W[es] ;B[iq];W[lb];B[hq];W[ir];B[kr];W[fi];B[mb];W[nm];B[ml];W[mo] ;B[nn];W[on];B[mn];W[lo];B[kn];W[jq];B[jp];W[ks];B[gm];W[kq] ;B[ls];W[lq];B[lr];W[fr];B[gq];W[hs];B[cp];W[eo];B[ep];W[jk] ;B[bg];W[ah];B[la];W[ka];B[kd];W[jl];B[jd];W[ma];B[kc];W[nb] ;B[mc];W[kb];B[gf];W[pb];B[ob];W[oa];B[qb];W[oc];B[eh];W[ei] ;B[ii];W[jg];B[bf];W[be];B[bc];W[bb];B[cd];W[cb];B[bd];W[ce] ;B[ob];W[rd];B[qe];W[oc];B[ia];W[pa];B[qa];W[jn];B[fn];W[am] ;B[jo];W[in];B[hn];W[sp];B[io];W[km];B[lk];W[ni];B[lm];W[mj] ;B[gb];W[ga];B[nh];W[ln];B[lc];W[la];B[fa];W[ea];B[im];W[jm] ;B[ko];W[sn];B[sh];W[gl];B[hl];W[bm];B[ob]) - ___ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go