Ticket #161 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Crash in atari-atari code

Reported by: arend Owned by: gnugo
Priority: normal Milestone: 3.7.11
Component: source Version:
Severity: blocker Keywords:
Cc: patch: yes

Description

Current CVS gnugo (r2375) crashes in compute_aa_status when loading the attached game.

gnugo -l atari-crash.sgf

***assertion failure:
board.c:2727 - ON_BOARD1(pos) near PASS***

W:J9
   A B C D E F G H J
 9 X . O X O O . O O 9
 8 X . O X X O O X X 8
 7 X . O X X . O . O 7
 6 O . O O X X X O . 6
 5 . O O . O O X O X 5
 4 O O . O . O X X X 4
 3 X O O O O X X . . 3
 2 . O X X X X . . . 2     WHITE (O) has captured 6 stones
 1 O O O O X X . . . 1     BLACK (X) has captured 0 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[ec];W[ee];B[cf];W[dd];B[dc];W[cd];B[ge];W[eg];B[gg];W[be];B[eh];W[dg]
;B[fh];W[cc];B[dh];W[cg];B[fd];W[cb];B[ch];W[fa];B[bg];W[bf];B[ed];W[bh]
;B[gf];W[gc];B[eb];W[ea];B[da];W[gb];B[db];W[hd];B[gd];W[he];B[hf];W[bi]
;B[ie];W[ic];B[hb];W[ha];B[ib];W[fb];B[ef];W[df];B[if];W[ca];B[de];W[ff]
;B[fg];W[ce];B[ac];W[fe];B[ab];W[ad];B[aa];W[ci];B[ah];W[di];B[ag];W[af]
;B[fi];W[ai];B[ag];W[bg];B[ei]
)
gnugo 3.7.10 (seed 1169332980): You stepped on a bug.
Please mail this message, including the debug output above, to gnugo@gnu.org


Program received signal SIGABRT, Aborted.
0xb7efa410 in ?? ()
(gdb) bt
#0  0xb7efa410 in ?? ()
#1  0xbfa3cdcc in ?? ()
#2  0x00000006 in ?? ()
#3  0x000049b6 in ?? ()
#4  0xb7d59060 in raise () from /lib/libc.so.6
#5  0xb7d5a801 in abort () from /lib/libc.so.6
#6  0x0808ea04 in abortgo (file=0x81023fc "board.c", line=2727,
    msg=0x810228d "ON_BOARD1(pos)", pos=0) at printutils.c:296
#7  0x0805e5c2 in is_self_atari (pos=18870, color=2) at board.c:2727
#8  0x0806425b in compute_aa_status (color=2,
    safe_stones=<value optimized out>) at combination.c:583
#9  0x08065aae in atari_atari_blunder_size (color=1, move=29,
    defense_moves=0xbfa3d490 "", safe_stones=0x0) at combination.c:416
#10 0x080aee13 in blunder_size (move=29, color=1, defense_point=0xbfa3e388,
    safe_stones=0x0) at utils.c:1029
#11 0x080af976 in confirm_safety (move=29, color=1, defense_point=0xbfa3e388,
    safe_stones=0x0) at utils.c:962
#12 0x080bd932 in filllib_confirm_safety (move=29, color=1,
    defense_point=0xbfa3e388) at filllib.c:620
#13 0x080be058 in fill_liberty (move=0xbfa3ebdc, color=1) at filllib.c:256
#14 0x0806c75a in do_genmove (color=1, pure_threat_value=0.400000006,
    allowed_moves=0x0, value=0xbfa3ec3c, resign=0x0) at genmove.c:481
#15 0x0806ce68 in genmove (color=0, value=0x49b6, resign=0x0) at genmove.c:263
#16 0x08055b1c in load_and_analyze_sgf_file (gameinfo=0xbfa42cec)
    at play_solo.c:156
#17 0x0804a9b2 in main (argc=3, argv=0xbfa42dd4) at main.c:1075

Attachments

atari-crash.sgf Download (462 bytes) - added by arend 4 years ago.
gunnar_7_11.5.diff Download (1.8 KB) - added by gunnar 4 years ago.
Possible fix.
gunnar_7_11.5b.diff Download (4.0 KB) - added by gunnar 3 years ago.
Previous patch + addition of the crashing position as new testcase.

Regression Results

Attachment Rev. PASS FAIL Nodes Status
gunnar_7_11.5.diff Download 2381 1 -0.37% -0.27% -0.086% details
gunnar_7_11.5b.diff Download never tested

Change History

Changed 4 years ago by arend

  Changed 4 years ago by gunnar

  • severity changed from normal to blocker
  • milestone changed from 3.8 to 3.7.11

The problem is that in atari_atari_blunder_size(), compute_aa_status() is called for stackp>0 despite that it relies on worm and dragon data. What more specifically causes the crash is that a liberty count from the worm data says a string has two liberties but when those are computed with findlib the preceding trymove() has eliminated one of the liberties.

Changed 4 years ago by gunnar

Possible fix.

  Changed 4 years ago by gunnar

  • patch set

The attached patch gunnar_7_11.5 solves this crash, although it has not been tested on anything else and might break something.

  Changed 4 years ago by gunnar

Regression results:

ninestones:220  FAIL R9 [P9|P8]
1 FAIL
Total nodes: 1701894161 3327144 12478660 (-0.36% -0.27% -0.085%)

  Changed 4 years ago by gunnar

It turns out that this problem was introduced in r2299, see ticket #77. Thus the problem is now to find an effective solution of ninestones:220.

follow-up: ↓ 6   Changed 4 years ago by draqo

My patch from ticket 162 (which changes access from worm_data to string_data) fixes it. As for regressions look on a comment in this ticket - anyway, after applying tickets 162, 163 and 164, ninestones:220 doesn't fail and there is no crash.

in reply to: ↑ 5   Changed 4 years ago by draqo

Replying to draqo:

My patch from ticket 162 (which changes access from worm_data to string_data) fixes it. As for regressions look on a comment in this ticket - anyway, after applying tickets 162, 163 and 164, ninestones:220 doesn't fail and there is no crash.

What makes ninestones:220 doesn't work is moving the place where compute_aa_status and compute_aa_values are called. So I won't make any changes in my patch and this ticket should be left to repair ninestones:220.

Changed 3 years ago by gunnar

Previous patch + addition of the crashing position as new testcase.

  Changed 3 years ago by gunnar

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.