gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Another bug report


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Another bug report
Date: Wed, 05 Dec 2001 17:40:53 +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)

Hi Markus,

Thanks for the bug reports.

> another bug occurred to me with GnuGo 3.0.0, this time with an assertion:
> [...]
> The file is appended in SGF format (note that the y axis is mirrored
> in the file, this is the fault of NeuroGo). The assertion happened
> after playing 40 games in a row on 9x9 and is not reproducible
> after loadsgf.

The persistent caching of various reading results is the primary
suspect for these problems. Although it's not possible to reproduce
them by using loadsgf it should be possible to reproduce them by
feeding the engine the full sequence of GTP commands. This is
obviously a very time consuming recipe, but it should at least give a
chance to track the bug down.

It seems like you are hit by these problems often enough that you may
be able to help us by providing a test case. This would require that
you modify the GTP controller to log all commands sent to GNU Go in a
file. Then when an illegal move is generated or an assertion fails,
the contents of the log file should allow reproduction. Hopefully this
happens sooner rather than later.

So what we need is such a log file. It will probably be quite big so
mail it just to me rather than to the whole list. Alternatively, if
it's convenient for you, make it available on an ftp or www server.

Thinking of it, it might be useful also with a log of GNU Go's
responses, just to see that there's no divergence in the processing.

/Gunnar Farneb?ck



reply via email to

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