Ticket #190 (closed defect: fixed)
Assertion failure
| Reported by: | gunnar | Owned by: | gunnar |
|---|---|---|---|
| Priority: | highest | Milestone: | 3.7.11 |
| Component: | source | Version: | |
| Severity: | blocker | Keywords: | |
| Cc: | patch: | yes |
Description
Loading the attached sgf file causes an assertion failure in the board code.
***assertion failure: board.c:1481 - IS_STONE(board[str]) near A2*** B:A1 W:J9 (variation 24206) A B C D E F G H J 9 . . . X . . O . O 9 8 . . X O O O . O X 8 7 . . X X O . O X . 7 6 . . . . O X O X X 6 5 . . X . X O O O X 5 4 . X . . . X O X . 4 3 X O O . O X O X . 3 2 . X O O O X X . . 2 WHITE (O) has captured 2 stones 1 X X O . O . . . . 1 BLACK (X) has captured 2 stones A B C D E F G H J (;GM[1]FF[4]SZ[9]KM[7.5]HA[0]GN[GNU Go 3.7.10 stepped on a bug] ;B[ee];W[eg];B[ff];W[cg];B[dc];W[gc];B[fg];W[dh];B[ce];W[he];B[fh];W[fb] ;B[bf];W[bg];B[hf];W[db];B[cb];W[ec];B[cc];W[ge];B[ag];W[ah];B[bi];W[ci] ;B[bh];W[eh];B[ie];W[ei];B[id];W[ch];B[fd];W[hb];B[da];W[gf];B[hd];W[gd] ;B[hg];W[eb];B[ib];W[ed];B[hc];W[fe];B[ha];W[ga];B[gb];W[gg];B[gh];W[hb] ) gnugo 3.7.10 (seed 1191530252): You stepped on a bug.
Attachments
Regression Results
| Attachment | Rev. | PASS | FAIL | Nodes | Status | |
| gunnar_7_11.10.diff | 2388 | 0% 0% 0% | details |
Change History
comment:1 Changed 4 years ago by gunnar
- Owner changed from gnugo to gunnar
- Status changed from new to assigned
The original position is like this
A B C D E F G H J 9 . . . X . . O X . 9 8 . . X O O O . O X 8 7 . . X X O . O X . 7 6 . . . . O X O X X 6 5 . . X . X O O O X 5 4 . X . . . X O X . 4 3 X O O . O X O X . 3 2 O X O O O X X . . 2 WHITE (O) has captured 2 stones 1 . X O . O . . . . 1 BLACK (X) has captured 2 stones A B C D E F G H J
and the best move is the illegal ko capture black G8. Then the ko threats are reevaluated, including the threat to capture A2. (This is only a threat because we don't consider snapback captures as proper captures.) The analysis goes black A1 - white J9, i.e. white wins the ko. Does black then have a proper attack at A2? Oops, A2 is gone and there's eventually an assertion failure when countlib() is called on the empty vertex.
It seems to me that an adequate solution in the case when the stone threatened by an attack is gone is to see whether the threatening move can be defended instead. In this case even that fails due to a shortage of liberties.
What's bothering me is why we haven't run into this before. This can't be all that rare, can it?


Crashing position.