[gnugo-devel] Segfault on 2x2 gamefields

[Alex Ponebshek]

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.

address@hidden:~/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
address@hidden 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
address@hidden:~/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...

address@hidden:~/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.