gnugo segfaults after the player makes a move on a 2x2 grid (--boardsize
2). If the computer is black, it plays normally, and then it crashes
after the player moves (or even passes)...
Seems to happen reliably.
a...@contingency:~/Downloads/gnugo-3.8$ valgrind ./interface/gnugo
--boardsize 2 --color white
==27386== Memcheck, a memory error detector
==27386== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==27386== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
copyright info
==27386== Command: ./interface/gnugo --boardsize 2 --color white
==27386==
GNU Go 3.8
Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
2008 and 2009 by the Free Software Foundation, Inc.
See http://www.gnu.org/software/gnugo/ or contact
gn...@gnu.org for information about GNU Go. GNU Go comes with NO WARRANTY to
the extent permitted by law. This program is free software; you can
redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation - version 3 or
(at your option) any later version. For more
information about these matters, see the files named COPYING.
Beginning ASCII mode game.
Board Size: 2
Handicap 0
Komi: 0.0
Move Number: 0
To Move: black
Computer player: Black
black(1): B2
White (O) has captured 0 pieces
Black (X) has captured 0 pieces
A B Last move: Black B2
2 .(X)2
1 . . 1
A B
white(2): a1
==27386== Invalid read of size 8
==27386== at 0x4B7474: sgfAddPlay (sgfnode.c:498)
==27386== by 0x4B8137: sgftreeAddPlay (sgftree.c:142)
==27386== by 0x4056EA: do_move (play_ascii.c:534)
==27386== by 0x4063D7: play_ascii (play_ascii.c:818)
==27386== by 0x40234B: main (main.c:1463)
==27386== Address 0x2b000636653b is not stack'd, malloc'd or (recently)
free'd
==27386==
==27386==
==27386== Process terminating with default action of signal 11 (SIGSEGV)
==27386== Access not within mapped region at address 0x2B000636653B
==27386== at 0x4B7474: sgfAddPlay (sgfnode.c:498)
==27386== by 0x4B8137: sgftreeAddPlay (sgftree.c:142)
==27386== by 0x4056EA: do_move (play_ascii.c:534)
==27386== by 0x4063D7: play_ascii (play_ascii.c:818)
==27386== by 0x40234B: main (main.c:1463)
==27386== If you believe this happened as a result of a stack
==27386== overflow in your program's main thread (unlikely but
==27386== possible), you can try to increase the size of the
==27386== main thread stack using the --main-stacksize= flag.
==27386== The main thread stack size used in this run was 8388608.
==27386==
==27386== HEAP SUMMARY:
==27386== in use at exit: 11,538,388 bytes in 26 blocks
==27386== total heap usage: 37 allocs, 11 frees, 11,541,368 bytes
allocated
==27386==
==27386== LEAK SUMMARY:
==27386== definitely lost: 0 bytes in 0 blocks
==27386== indirectly lost: 0 bytes in 0 blocks
==27386== possibly lost: 0 bytes in 0 blocks
==27386== still reachable: 11,538,388 bytes in 26 blocks
==27386== suppressed: 0 bytes in 0 blocks
==27386== Rerun with --leak-check=full to see details of leaked memory
==27386==
==27386== For counts of detected and suppressed errors, rerun with: -v
==27386== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault
a...@contingency:~/Downloads/gnugo-3.8$
(and I realize there's no point in playing 2x2 go, just something I
noticed...)
After removing offending lines of source code like a wreckless fool,
gnugo miraculously ran without incident, and I soundly defeated it in 2x2...
a...@contingency:~/Downloads/gnugo-3.8$ ./interface/gnugo --boardsize 2
--color white --komi 5.5
A B Last move: Black B2
2 .(X)2
1 . . 1
A B
A B Last move: White A1
2 . X 2
1(O). 1
A B
A B Last move: Black PASS
2 . X 2
1 O . 1
A B
white(4): pass
black(5): PASS
Result: W+5.5
Thanks! for playing GNU Go.
I hope this makes me the first person to beat gnugo in 2x2.
_______________________________________________
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
