[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] about one GNU Go 3.7.7 windows build's test case( cras
From: |
Gunnar Farnebäck |
Subject: |
Re: [gnugo-devel] about one GNU Go 3.7.7 windows build's test case( crash ) |
Date: |
Wed, 11 Jan 2006 14:47:10 +0100 |
User-agent: |
EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI) |
Cai wrote:
> I build gnugo with VC++ 7 in debug mode
>
> When crashs, it prompts:
>
> Debug Error!
>
> Program: gnugo-3.7.7\interface\gnugo.exe
> Module: gnugo-3.7.7\interface\gnugo.exe
> File: gnugo-3.7.7\engine\optics.c
> Line: 1552
>
> Run-Time Check Failure #2 - Stack around the variable 'vpos' was corrupted.
No idea what this may be. I can't reproduce it on linux, neither does
valgrind indicate any problem in the optics code. Do you have tools
and knowledge to debug this any further?
> During my building, GNU Go 3.7.7 's windows build seems broken. I
> manual built the uncompress_fuseki.c and generated fuseki[9,13,19].c
There are some windows build fixes in CVS after 3.7.7 but not related
to uncompress_fuseki, as far as I know. In general windows build fixes
need to be contributed by the people who have the necessary tools.
> I also built 3.7.7 in my linux box and executed the test case. It
> workd fine(produce "A4", though I think the best move should be B3).
Yes, B3 is a simpler and safer move.
> By the way, I think the move 102 is not best. It made left-bottom
> group gains zero points. It should be A4|A3.
B5 suffices to live with territory too.
> But it's strange that gnugo produce B5 at game and when I use
> test.sh to reproduce it, it produce C6 though I use same command
> line to call gnugo.
That might be a persistent cache problem. Potentially it could also be
a question of different random seeds in case the moves are identically
valued, but that seems less likely.
/Gunnar