[Top][All Lists]
[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;
}