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
