gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Bug report


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Bug report
Date: Fri, 23 Jan 2004 01:23:33 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

I wrote:
> This looks kind of weird. I have no idea what could cause it. To get
> further it could help with a backtrace (if you know how to produce
> one) but even better would be a GTP command sequence to reproduce the
> crash.

After some brainstorming on NNGS, I found the cause of this crash. To
reproduce it, run the following GTP commands in the regression
directory:

loadsgf games/semeai/semeaiko1.sgf
reg_genmove black
boardsize 9
genmove black

The problem is that when the board is empty, make_dragons() is not
run, only initialize_dragon_data(). In that case
initialize_supplementary_dragon_data() is not reached. Usually this is
not a problem but if a previous move have been generated on a
non-empty board (such as in an earlier game in a GTP session),
number_of_dragons and the dragon2[] array contain invalid data. If
additionally the previous game was played on a larger board and the
last move involved semeai move reasons, this particular crash may
follow.

Appended is a simple fix for the problem. A better fix would be to
always call make_dragons(), also for an empty board, and if still
needed have special casing for the empty board at a lower level.

- number_of_dragons initialized in initialize_dragon_data()

> In order to do that you need to take the following steps:
> 
> 1. Apply the appended patch, alternatively wait for GNU Go 3.5.4
>    (might take a while).
> 2. Add the option "--gtp-dump-commands kgs_commands.gtp" when starting
>    GNU Go. For maximum reproducability it would also be good to use
>    the option "-r 1" to set the initial random seed. The number can be
>    chosen arbitrarily of course as long as you report what it is.
> 3. Wait for a crash, then send us the kgs_commands.gtp file. However,
>    unless it's quite small (it probably isn't) it's better to either
>    make it available over www or ftp (if you have the resources) or
>    send it separately to me.

Well, this doesn't hurt if some other crash inducing bug should be
found, but this particular problem has been solved now.
 
/Gunnar

Index: engine/dragon.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/dragon.c,v
retrieving revision 1.129
diff -u -r1.129 dragon.c
--- engine/dragon.c     20 Jan 2004 22:57:40 -0000      1.129
+++ engine/dragon.c     23 Jan 2004 00:20:26 -0000
@@ -696,6 +696,15 @@
              str, worm[str].size);
     }
   memset(next_worm_list, 0, sizeof(next_worm_list));
+
+  /* We need to reset this to avoid trouble on an empty board when
+   * moves have previously been generated for a non-empty board.
+   *
+   * Comment: The cause of this is that make_dragons() is not called
+   * for an empty board, only initialize_dragon_data(), so we never
+   * reach initialize_supplementary_dragon_data().
+   */
+  number_of_dragons = 0;
 }
 
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]