check the output of `dmesg' to see if it segfaulted
and/or ulimit -c unlimited so that you will find a core file
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
-go] Strange GNU Go ladder behavior
CentOS Linux release 7.1.1503
64 bit
I'm not sure which compiler the make script invoked, but I have these
installed:
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
cc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9
:22 PM
Subject: Re: [Computer-go] Strange GNU Go ladder behavior
CentOS Linux release 7.1.1503
64 bit
I'm not sure which compiler the make script invoked, but I have these
installed:
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
cc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9
Configure doesn't seem happy with that:
I'm not familiar with CentOS, but maybe need to install
# yum -y install glibc-devel.i386 libstdc++-devel.i386
or
# yum -y install glibc-devel.i686 glibc-devel ibstdc++-devel.i686
Hiroshi Yamashita
___
So what is the 64-bit problem? (Or did I misread?)
On Jun 19, 2015 8:04 PM, Peter Drake dr...@lclark.edu wrote:
Okay, that worked (with the correction that ibstdc should be libstdc).
The new version doesn't choke on my sgf file!
Now for the acid test, running the whole experiment...
On
I got through the whole 640-game experiment without a crash!
(The cloud is a wonder, allowing me to play 640 games in under an hour.)
Many thanks to everyone for your help.
One game did run very long, thanks to GNU Go. See the time left signals in
the SGF:
Okay, that worked (with the correction that ibstdc should be libstdc).
The new version doesn't choke on my sgf file!
Now for the acid test, running the whole experiment...
On Fri, Jun 19, 2015 at 4:43 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote:
Configure doesn't seem happy with that:
I don't know the details, but apparently GNU Go has some subtle
instabilities when compiled for 64 bits. I would guess that it has to do
with the fact that in C, the sizes of primitive types are
platform-dependent.
On Fri, Jun 19, 2015 at 8:12 PM, uurtamo . uurt...@gmail.com wrote:
So what is
[drake@broadcast ~]$ gnugo --infile
results/2015/06/19/03:21:15.950/instance17-b1-2015-06-19-03:21:31.287.sgf
Segmentation fault
Your sgf is ok on theres 4 environments. It took about 1 minute though.
GNU Go 3.9.1 gcc 4.1.2, Debian 4.1.1-21, 32bit
GNU Go 3.8 gcc 4.1.2, Debian 4.1.1-21,
CentOS Linux release 7.1.1503
64 bit
I'm not sure which compiler the make script invoked, but I have these
installed:
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
cc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
On Fri, Jun 19, 2015 at 12:45 AM, Hiroshi Yamashita y...@bd.mbn.or.jp
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ubunut 12.04 (64 bit) self compiled with
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
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
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
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
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
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
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.
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
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
19 matches
Mail list logo
