Ticket #190 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

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

crash.sgf Download (358 bytes) - added by gunnar 4 years ago.
Crashing position.
gunnar_7_11.10.diff Download (764 bytes) - added by gunnar 4 years ago.
Patch solving the problem.

Regression Results

Attachment Rev. PASS FAIL Nodes Status
gunnar_7_11.10.diff Download 2388 0% 0% 0% details

Change History

Changed 4 years ago by gunnar

Crashing position.

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?

Changed 4 years ago by gunnar

Patch solving the problem.

comment:2 Changed 4 years ago by gunnar

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.