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 cr
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:
(;FF[4]CA[UTF-8]AP[Orego8]KM[7.5]GM[1]
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 . wrote:
> So what is the 64-bit problem
So what is the 64-bit problem? (Or did I misread?)
On Jun 19, 2015 8:04 PM, "Peter Drake" 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 Fri, Ju
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 wrote:
> Configure doesn't seem happy with that:
>>
>
> I'm not fam
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
___
Compute
in'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## --- ##
## confdefs.h. ##
## --- ##
#define PACKAGE_NAME "gnugo"
#define PACKAGE_TARNAME "gnugo"
#define PACKAGE_VERSION "3
2015 11: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)
__
-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
4.8.2-19ub
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
wrote:
> [drake@broadcast ~]$ gnugo -
[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, 32
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/
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 issuin
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.
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 wrote:
> Hi!
>
> I've observed the same thing w
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
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 wrote:
> I have no idea what GNU G
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
thin
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" 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 playin
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, bu
20 matches
Mail list logo