1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
Pre-existing WalkPV assertion crash (util.c:1093), found 2026-09-08
during the board-representation-migration self-play investigation.
STATUS: confirmed pre-existing on unmodified HEAD (434fa04), NOT
introduced by any of that session's changes. Not yet root-caused.
Reproduces intermittently depending on accumulated hash-table state,
not on the triggering FEN alone in isolation.
Repro (DEBUG build, asserts compiled in):
./_typhoon --batch --command "force; setboard rnb1r1k1/pp5p/2pp2p1/4b3/2P1P2q/1NN1BPp1/PP1QB1P1/3RR1K1 b - -; sd 5; go"
Crash happens during the *subsequent* Ponder() call after the "go"
search completes (visible as "_[pondering ...] white(move 1)_" in the
output right before the assertion) -- NOT during the sd 5 search
itself. A bare "sd 5; go" against this FEN with no prior search history
in the process did NOT reproduce it in at least one isolated attempt;
it may depend on hash-table/PV state accumulated from prior searches
in the same process (same category as the second crash found the same
day, recogn.c:1359 _SanityCheckRecognizers -- also state-dependent,
also confirmed pre-existing on 434fa04).
Backtrace (gdb, DEBUG build at 434fa04):
#0 SystemDebugBreakpoint () at unix.c:405
#1 _assert (...) at util.c:824
#2 WalkPV (ctx=0x25d918 <Ponder.ctx>) at util.c:1093
#3 UtilPrintPV (ctx=..., iAlpha=-421, iBeta=32767, iScore=39, mv=...) at util.c:1214
#4 RootSearch (ctx=..., iAlpha=-32767, iBeta=32767, uDepth=80) at root.c:857
#5 Iterate (ctx=...) at root.c:1287
#6 Ponder (pos=...) at root.c:1592
#7 MainProgramLoop () at main.c:695
#8 main (argc=4, argv=...) at main.c:757
At the point of the crash (frame 2, WalkPV locals):
u = 2, v = 1
ctx->sPlyInfo[v].PV[u] == HASHMOVE (uMove = 286361736,
cFrom = 136 (0x88, the illegal/off-board sentinel coordinate),
cTo = 136, pMoved = pCaptured = pPromoted = 1, bvFlags = 1)
ctx->sPlyInfo[v].PV[u+1] == the SAME non-zero value as PV[u]
WalkPV's <TT> branch (util.c ~1089-1093) matches
`mv.uMove == HASHMOVE.uMove`, then asserts the *next* PV slot is the
zero-terminator:
ASSERT(ctx->sPlyInfo[v].PV[u+1].uMove == 0);
but PV[u+1] holds the same non-zero "garbage-looking" value as PV[u],
so the assert fires. HASHMOVE itself looks corrupt/never-properly-set
here -- cFrom == cTo == the illegal-square sentinel (0x88) rather than
a real move or a clean zero, which reads like leftover/uninitialized
state being compared as if it were a legitimate hash move.
Not yet investigated further: whether HASHMOVE is stale from a
previous ply/search, whether it's a genuine PV-array corruption during
Ponder specifically (pondering is the only reproduction path found so
far), or something else. This file exists so the exact repro isn't
lost to a later smoke_test run overwriting the same sample filename.
|
