Re: [Computer-go] Strange GNU Go ladder behavior
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 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 Folkert van Heusden -- Ever wonder what is out there? Any alien races? Then please support the seti@home project: setiathome.ssl.berkeley.edu -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com ___ 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
' for more details.
## ##
## Cache variables. ##
## ##
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=-m32
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=-m32
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=i686-pc-linux-gnu
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_path_install='/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_make_make_set=yes
## - ##
## Output variables. ##
## - ##
ACLOCAL='${SHELL} /home/drake/gnugo-3.8/missing --run aclocal-1.9'
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL} /home/drake/gnugo-3.8/missing --run tar'
AUTOCONF='${SHELL} /home/drake/gnugo-3.8/missing --run autoconf'
AUTOHEADER='${SHELL} /home/drake/gnugo-3.8/missing --run autoheader'
AUTOMAKE='${SHELL} /home/drake/gnugo-3.8/missing --run automake-1.9'
AWK='gawk'
CC='gcc'
CCDEPMODE=''
CFLAGS='-m32'
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
DFA_ENABLED_FALSE=''
DFA_ENABLED_TRUE=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
GCC_MAJOR_VERSION=''
GCC_MINOR_VERSION=''
GCC_ONLY_FALSE=''
GCC_ONLY_TRUE=''
GNU_GO_WARNINGS=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
LDFLAGS='-m32'
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
MAINT='#'
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE='#'
MAKEINFO='${SHELL} /home/drake/gnugo-3.8/missing --run makeinfo'
OBJEXT=''
PACKAGE='gnugo'
PACKAGE_BUGREPORT=''
PACKAGE_NAME='gnugo'
PACKAGE_STRING='gnugo 3.8'
PACKAGE_TARNAME='gnugo'
PACKAGE_VERSION='3.8'
PATH_SEPARATOR=':'
RANLIB=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
VERSION='3.8'
ac_ct_CC='gcc'
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - $$tardir'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build_alias='i686-pc-linux-gnu'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
glibconfig=''
host_alias=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='/home/drake/gnugo-3.8/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='mkdir -p --'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='NONE'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
## --- ##
## confdefs.h. ##
## --- ##
#define PACKAGE_NAME gnugo
#define PACKAGE_TARNAME gnugo
#define PACKAGE_VERSION 3.8
#define PACKAGE_STRING gnugo 3.8
#define PACKAGE_BUGREPORT
#define PACKAGE gnugo
#define VERSION 3.8
#define GNU_PACKAGE GNU gnugo
configure: exit 77
On Fri, Jun 19, 2015 at 1:54 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote:
It seems GNU Go built in 64bit has some problems.
I got crash on 64bit, but 32bit binary on 64 bit debian was ok.
Try to build 32bit binary GNU Go.
$ tar xvf gnugo-3.8.tar.gz
$ cd gnugo-3.8
$ ./configure --build=i686-pc-linux-gnu CFLAGS=-m32 CXXFLAGS=-m32
LDFLAGS=-m32
$ make
yss@debian:~/gnugo-3.8/interface$ ./gnugo -l crashes-gnugo.sgf
white (O) move J8
yss@debian:~/gnugo-3.8/interface$ gcc -v
gcc version 4.7.2 (Debian 4.7.2-5)
Regards,
Hiroshi Yamashita
- Original Message - From: Peter Drake dr...@lclark.edu
To: computer-go@computer-go.org
Sent: Friday, June 19, 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)
___
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
It seems GNU Go built in 64bit has some problems. I got crash on 64bit, but 32bit binary on 64 bit debian was ok. Try to build 32bit binary GNU Go. $ tar xvf gnugo-3.8.tar.gz $ cd gnugo-3.8 $ ./configure --build=i686-pc-linux-gnu CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 $ make yss@debian:~/gnugo-3.8/interface$ ./gnugo -l crashes-gnugo.sgf white (O) move J8 yss@debian:~/gnugo-3.8/interface$ gcc -v gcc version 4.7.2 (Debian 4.7.2-5) Regards, Hiroshi Yamashita - Original Message - From: Peter Drake dr...@lclark.edu To: computer-go@computer-go.org Sent: Friday, June 19, 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) ___ 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
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 ___ 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
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 Fri, Jun 19, 2015 at 4:43 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote: 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 ___ 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 ___ 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 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]RU[Chinese]SZ[19] PB[/usr/local/bin/gnugo --boardsize 19 --mode gtp --quiet --chinese-rules --capture-all-dead --positional-superko --komi 7.5] PW[/usr/bin/java -cp /home/drake/Orego/bin/ -ea -Xmx1024M edu.lclark.orego.ui.Orego boardsize=19 komi=7.5 memory=1024 shape shape-bias=10 shape-minstones=3 shape-scaling-factor=0.999 log-file=logging] ;B[dp]BL[500] ;W[pd]WL[500] ;B[pq]BL[500] ;W[cd]WL[500] ;B[ed]BL[500] ;W[ec]WL[500] ;B[fc]BL[500] ;W[dc]WL[500] ;B[qf]BL[499] ;W[qj]WL[493] ;B[fd]BL[499] ;W[fb]WL[486] ;B[gb]BL[499] ;W[gc]WL[480] ;B[hc]BL[497] ;W[gd]WL[473] ;B[ge]BL[495] ;W[hd]WL[466] ;B[id]BL[492] ;W[he]WL[459] ;B[hf]BL[488] ;W[ie]WL[453] ;B[je]BL[480] ;W[if]WL[446] ;B[ig]BL[473] ;W[jf]WL[439] ;B[kf]BL[462] ;W[jg]WL[433] ;B[jh]BL[447] ;W[kg]WL[427] ;B[lg]BL[426] ;W[kh]WL[420] ;B[ki]BL[401] ;W[lh]WL[414] ;B[mh]BL[365] ;W[li]WL[408] ;B[lj]BL[302] ;W[mi]WL[401] ;B[ni]BL[234] ;W[mj]WL[395] ;B[mk]BL[99] ;W[nj]WL[389] ;B[oj]BL[-29] ;W[nk]WL[383] ;B[nl]BL[-190] ;W[ok]WL[377] ;B[pk]BL[-357] ;W[ol]WL[371] ;B[om]BL[-616] ;W[pl]WL[366] ;B[ql]BL[-849] ;W[pm]WL[360] ;B[pn]BL[-1231] ;W[qm]WL[354] ;B[rm]BL[-1668] ;W[qn]WL[348] ;B[qo]BL[-2149] ;W[rn]WL[343] ;B[ro]BL[-2208] ;W[sn]WL[337] ;B[so]BL[-2248] ;W[pf]WL[332] ;B[cf]BL[-2253] ;W[de]WL[326] ;B[dh]BL[-2255] ;W[cj]WL[321] ;B[ej]BL[-2257] ;W[ek]WL[316] ;B[pg]BL[-2259] ;W[qg]WL[310] ;B[qh]BL[-2267] ;W[ph]WL[305] ;B[rg]BL[-2278] ;W[eg]WL[300] ;B[df]BL[-2288] ;W[ef]WL[295] ;B[ee]BL[-2295] ;W[og]WL[290] ;B[pi]BL[-2309] ;W[qi]WL[285] ;B[oh]BL[-2318] ;W[pb]WL[280] ;B[dj]BL[-2324] ;W[di]WL[275] ;B[ci]BL[-2329] ;W[ei]WL[270] ;B[ck]BL[-2337] ;W[dk]WL[266] ;B[bj]BL[-2344] ;W[bf]WL[261] ;B[be]BL[-2348] ;W[dg]WL[256] ;B[bg]BL[-2359] ;W[cg]WL[252] ;B[af]BL[-2365] ;W[bh]WL[247] ;B[ch]BL[-2373] ;W[ag]WL[243] ;B[bf]BL[-2382] ;W[bd]WL[238] ;B[fj]BL[-2385] ;W[ae]WL[234] ;B[ad]BL[-2388] ;W[ac]WL[230] ;B[fk]BL[-2392] ;W[fl]WL[225] ;B[el]BL[-2394] ;W[ah]WL[221] ;B[ai]BL[-2398] ;W[ce]WL[217] ;B[bi]BL[-2405] ;W[bh]WL[213] ;B[gl]BL[-2409] ;W[ag]WL[209] ;B[ah]BL[-2414] ;W[gk]WL[205] ;B[fm]BL[-2419] ;W[lk]WL[201] ;B[sm]BL[-2438] ;W[dl]WL[198] ;B[bc]BL[-2441] ;W[en]WL[194] ;B[fo]BL[-2443] ;W[fn]WL[191] ;B[gn]BL[-2444] ;W[go]WL[188] ;B[fp]BL[-2446] ;W[bk]WL[184] ;B[ho]BL[-2449] ;W[gj]WL[181] ;B[pe]BL[-2451] ;W[gp]WL[178] ;B[gq]BL[-2454] ;W[hp]WL[175] ;B[io]BL[-2457] ;W[hn]WL[171] ;B[gm]BL[-2463] ;W[hl]WL[168] ;B[kl]BL[-2467] ;W[ep]WL[165] ;B[eo]BL[-2478] ;W[fq]WL[162] ;B[do]BL[-2487] ;W[em]WL[159] ;B[hq]BL[-2498] ;W[ip]WL[156] ;B[jp]BL[-2511] ;W[iq]WL[153] ;B[ir]BL[-2526] ;W[jq]WL[150] ;B[kq]BL[-2540] ;W[jr]WL[147] ;B[kr]BL[-2564] ;W[js]WL[144] ;B[ks]BL[-2583] ;RE[B+Resign] ;C[moves:155] ;C[starttime:Sat Jun 20 03:22:53 UTC 2015] ;C[endtime:Sat Jun 20 04:20:17 UTC 2015] ) On Fri, Jun 19, 2015 at 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 Fri, Jun 19, 2015 at 4:43 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote: 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 ___ 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
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'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 ___ 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 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 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 Fri, Jun 19, 2015 at 4:43 PM, Hiroshi Yamashita y...@bd.mbn.or.jp wrote: 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 ___ 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 ___ 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
[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, 32bit GNU Go 3.7.10 gcc 4.1.2, Debian 4.1.1-21, 32bit GNU Go 3.7.10 Visual C++6.0, Windows XP, 32bit Result are same. yss@debian:~/gnugo-3.7.10/interface$ ./gnugo -l crashes-gnugo.sgf white (O) move J8 What kind of OS, 32bit or 64bit, and compiler makes crash? Regards Hiroshi Yamashita ___ 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
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: [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, 32bit GNU Go 3.7.10 gcc 4.1.2, Debian 4.1.1-21, 32bit GNU Go 3.7.10 Visual C++6.0, Windows XP, 32bit Result are same. yss@debian:~/gnugo-3.7.10/interface$ ./gnugo -l crashes-gnugo.sgf white (O) move J8 What kind of OS, 32bit or 64bit, and compiler makes crash? Regards Hiroshi Yamashita ___ 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
-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-19ubuntu1' - --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs - --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr - --program-suffix=-4.8 --enable-shared --enable-linker-build-id - --libexecdir=/usr/lib --without-included-gettext - --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 - --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu - --enable-libstdcxx-debug --enable-libstdcxx-time=yes - --enable-gnu-unique-object --disable-libmudflap --enable-plugin - --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk - --enable-gtk-cairo - --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre - --enable-java-home - --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 - --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 - --with-arch-directory=amd64 - --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc - --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 - --with-multilib-list=m32,m64,mx32 --with-tune=generic - --enable-checking=release --build=x86_64-linux-gnu - --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) CRASHES $gnugo --infile crashes-gnugo.sgf Speicherzugriffsfehler (Speicherabzug geschrieben) Am 19.06.2015 um 16:22 schrieb Peter Drake: 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: [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, 32bit GNU Go 3.7.10 gcc 4.1.2, Debian 4.1.1-21, 32bit GNU Go 3.7.10 Visual C++6.0, Windows XP, 32bit Result are same. yss@debian:~/gnugo-3.7.10/interface$ ./gnugo -l crashes-gnugo.sgf white (O) move J8 What kind of OS, 32bit or 64bit, and compiler makes crash? Regards Hiroshi Yamashita ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVhCgQAAoJEInWdHg+Znf4XvsP/2l9y9aYaawdIXeK/3S5ygW3 bvUpOQ5ZN9ez/qg4HSRFVsekjaocEEf+KiJMFoIXVBB05WldQwTCqOU0LKRDhkk7 KhWw3ntpJNK29ACXqmADR7iEvtCh7sS3IksgZZ2GCheo9IV3SkcD/zWXsFvUKINq aGWtSUN7VSAqi9ndGlhAhaeclo1ZCaN9Sq/MA1W4Od6K2CVw5sRLNhQDOVD+1dzV AKqlXsnc49GWLSOHgRXBAlNaXcYRP/LUZ86aef1FTxhdSZOg7TwIAK7OB0c80LLo R7Cz+uj8TCoa+o2RIeomN7xYIQfK6rJyRztOW+is10M4t19ggqoO0792DcSpE+1s foAeFC3+EGF3fh8hNrnkzgF1r3GDMNrBEGzCxzAtyl8tDErRS0C8AHEW2pMAgUjN Pb/+zgTAXbaTaWMfHxeMc36u+rAjLOHqPaSityTm68mB54X1unwPy4G5mI+DOwYB 38YfIdIt13GqsaJnEzpsPRe7nauld/CrPeJV3zYcxAPl1uBu1IwEOHHuEFMzC2Sn 1uk8xJtr5EIm5mbc/JXNTYxkd8phM9iGkIthWFYZPFqTijpLFrUMwhqdPCwp7+zu nDZZRYdlIeTURmxxfNV/zsvx2sfQRhRfrtg8jHNoMF0I/XfLHn11ti59pLZhAlR4 k8SMp+guTXQ0AK8Rv1l/ =an2s -END PGP SIGNATURE- ___ 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 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
