gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] GNU Go 3.5.7 and latest CVS crash in KGS game


From: Arend Bayer
Subject: Re: [gnugo-devel] GNU Go 3.5.7 and latest CVS crash in KGS game
Date: Sun, 6 Jun 2004 05:54:42 +0200 (CEST)



On Sun, 6 Jun 2004, Gunnar Farneb?ck wrote:

> Tom wrote:
> > My robot (GnuGoCVS) blew chunks on move 127 of the attached game.  The 
> > following will cause an assertion failure with 3.5.7 and the latest CVS:
> > 
> > # gnugo -l 2004-06-03-R-no-GnuGoCVS.sgf -L 127
> > 
> > ***assertion failure:
> > owl.c:1408 - board[move] == EMPTY near J19***
> 
> Thanks for the report.

Indeed, and thanks for running the gnugo robot on KGS btw!

> This seems to be a fairly serious problem,
> where the tactical reading retrieves an occupied attack point from the
> (non-persistent) cache. If someone wants to help with it, add the
> patch below to get an assertion error closer to where the problem is.

The problem is a systematic hash collision, introduced by gunnar_5_7.11.
Gunnar, the problem is with restoring the random state in both
hash_init() and keyhash_init(): This means that both functions start
with the same state of the pseudo random number generator, meaning that
that they generate the same hash values. (In above position, the problem
was that white_hash[] is up to a shift of a few entries identical to
target1_hash[].)

Since these two functions are only called from init_gnugo() via
reading_cache_init(), and we call set_random_seed() right afterwards
anyway, I think we can just drop the saving and restoring of the
random state. Agree?

[Btw, the situation before gunnar_5_7.11 was, while not buggy, at least
extremely fragile -- it would have broken the moment someone changed
the order of calling hash_init() and keyhash_init().]

Arend

- don't restore random state in keyhash_init() and hash_init()


Index: engine/cache.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/cache.c,v
retrieving revision 1.44
diff -u -p -r1.44 cache.c
--- engine/cache.c      27 May 2004 00:08:46 -0000      1.44
+++ engine/cache.c      6 Jun 2004 03:41:50 -0000
@@ -64,12 +64,6 @@ keyhash_init(void)
   static int is_initialized = 0;
   
   if (!is_initialized) {
-    struct gg_rand_state state;
-    /* Since the hash initialization consumes a varying number of random
-     * numbers depending on the size of the Hash_data struct, we save the
-     * state of the random generator now and restore it afterwards.
-     */
-    gg_get_rand_state(&state);
     
     INIT_ARRAY(komaster_hash);
     INIT_ARRAY(kom_pos_hash);
@@ -77,7 +71,6 @@ keyhash_init(void)
     INIT_ARRAY(target2_hash);
     INIT_ARRAY(routine_hash);
     
-    gg_set_rand_state(&state);
     is_initialized = 1;
   }
 }
Index: engine/hash.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/hash.c,v
retrieving revision 1.27
diff -u -p -r1.27 hash.c
--- engine/hash.c       27 May 2004 00:08:47 -0000      1.27
+++ engine/hash.c       6 Jun 2004 03:41:50 -0000
@@ -80,22 +80,12 @@ hash_init_zobrist_array(Hash_data *array
 void
 hash_init(void)
 {
-  struct gg_rand_state state;
-
   if (is_initialized)
     return;
   
-  /* Since the hash initialization consumes a varying number of random
-   * numbers depending on the size of the Hash_data struct, we save the
-   * state of the random generator now and restore it afterwards.
-   */
-  gg_get_rand_state(&state);
-
   hash_init_zobrist_array(black_hash, BOARDMAX);
   hash_init_zobrist_array(white_hash, BOARDMAX);
   hash_init_zobrist_array(ko_hash, BOARDMAX);
-
-  gg_set_rand_state(&state);
   
   is_initialized = 1;
 }




reply via email to

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