Re: [gnugo-devel] bug

[Tristan Cazenave]

here is what give gcc --version :

gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In the example I sent, the twogtp command stopped on a broken pipe 
without displaying an assertion failure, this was only when I restarted 
gnugo with the gtpstream that I got the assertion failure. So it seems 
that the assertion failure did not occur in the twogtp command but in 
the gtpstream.

Now, I have just restarted gnugo 3.6-pre2 with the gtpstream that caused 
the error and it did not make an assertion failure, whereas it did so 
this morning. I am quite puzzled.

Is it possible that gnugo does not do the same things twice with the 
option -r 54 with the same gtpstream ?

I had a similar problem today, when gnugo crashed during a twogtp 
session, and did not crash when I gave it the twogtp stream :

***assertion failure:
matchpat.c:1019 - ON_BOARD1(pos) near [-65427]***

W:F5 B:D6 W:F6 B:E4 W:F7 B:G8
  A B C D E F G H J
9 . . . . . . . . . 9
8 . . . O . X X . . 8
7 . . + O X O + . . 7
6 . . . X O O X . . 6
5 . . . . X O . . . 5
4 . . . . X . . . . 4
3 . . + . . . + . . 3
2 . . . . . . . . . 2     WHITE (O) has captured 0 stones
1 . . . . . . . . . 1     BLACK (X) has captured 0 stones
  A B C D E F G H J
(;GM[1]FF[4]SZ[9]KM[5.5]GN[GNU Go 3.6-pre2 stepped on a bug]
;B[gd];W[ed];B[fb];W[db];B[ec];W[dc];B[ee]
)
gnugo 3.6-pre2 (seed 1391748806): You stepped on a bug.
Please mail this message, including the debug output above, to address@hidden


address@hidden wrote:

> > Hi,
> >
> > Here it is! After twogtp crashed, as gnugo saved the gtp commands, I ran 
> > ~/gnugo-3.6-pre2/interface/gnugo --mode gtp -r 54 < gnugo-black.gtp, and 
> > got :
> >
> > ***assertion failure:
> > owl.c:6129 - IS_STONE(board[pos]) near H7***
> >    
>
> Thanks, Tristan.
>
> What I don't understand is that Tristan's sgf output
> only shows 11 stones on the board. 
>
> However 24 moves have been played in the second game!
> This position does not seem to represent the same game
> at all. (Either game.)
>
> ***assertion failure:
> owl.c:6129 - IS_STONE(board[pos]) near H7***
>
> W:E7 B:F7 W:F8 B:G4 W:G8 B:G2 W:H4
>   A B C D E F G H J
> 9 . . . . . . . . . 9
> 8 . . . . . O O . . 8
> 7 . . + . O X + . . 7
> 6 . . . X O X . . . 6
> 5 . . . . + . . . . 5
> 4 . . . . O . X O . 4
> 3 . . + . . . + . . 3
> 2 . . . . . . X . . 2     WHITE (O) has captured 0 stones
> 1 . . . . . . . . . 1     BLACK (X) has captured 0 stones
>   A B C D E F G H J
> (;GM[1]FF[4]SZ[9]KM[5.5]GN[GNU Go 3.6-pre2 stepped on a bug]
> ;B[fd];W[ef];B[dd];W[ed]
> )
>
> I tried this gtpstream on two machines. With gcc 3.3.3 there
> was no problem, but with the obsolete gcc 2.96 20000731 I got
> a different outputstream.
>
> The moves are identical for the first game but the
> scores differ. With gcc 3.3.3 the final score is
> B+12.5 while with gcc 2.96, the final score is B+13.5.
>
> The moves begin to diverge in the second game. With
> gcc 3.3.3 B generates the following moves:
>
> F6 D6 E7 G6 C6 F7 B8 C8 B6 A7 G8 A9
>
> Here is the final position:
>
>   A B C D E F G H J
> 9 X . . . . . . . . 9
> 8 . X X O O O X . . 8
> 7 X O O O X X + . . 7
> 6 . X X X O X X . . 6
> 5 . . . . O . . . . 5
> 4 . O . . O . . . . 4
> 3 . . + . . . + . . 3
> 2 . . . . . . . . . 2     WHITE (O) has captured 0 stones
> 1 . . . . . . . . . 1     BLACK (X) has captured 1 stones
>   A B C D E F G H J
>
> With gcc 2.69, B generates the following moves:
>
> F6 D6 E7 G6 C6 F7 C7 C4
>
> Then the input stream has W C7, so GNU complains about
> an illegal move. The game continues
>
> D3 C8 G8 B5
>
> and there is no crash.
>
>   A B C D E F G H J
> 9 . . . . . . . . . 9
> 8 O . X O O O X . . 8
> 7 . O X O X X + . . 7
> 6 . . X X O X X . . 6
> 5 . X . . O . . . . 5
> 4 . O X . O . . . . 4
> 3 . . + X . . + . . 3
> 2 . . . . . . . . . 2     WHITE (O) has captured 0 stones
> 1 . . . . . . . . . 1     BLACK (X) has captured 0 stones
>   A B C D E F G H J
>
> So I am seeing compiler variability but still cannot
> reproduce the crash.
>
> Dan
>
>
>