Ticket #161 (closed defect: fixed)
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
Regression Results
| Attachment | Rev. | PASS | FAIL | Nodes | Status | |
| gunnar_7_11.5.diff | 2381 | 1 | -0.37% -0.27% -0.086% | details | ||
| gunnar_7_11.5b.diff | never tested |
Change History
comment:1 Changed 5 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.
comment:2 Changed 5 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.
comment:3 Changed 5 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%)
comment:5 follow-up: ↓ 6 Changed 5 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.
comment:6 in reply to: ↑ 5 Changed 5 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 4 years ago by gunnar
-
attachment
gunnar_7_11.5b.diff
added
Previous patch + addition of the crashing position as new testcase.
