714c74565f
resume_reliability.sh counts, per boot, whether the title's loader thread became the CALLER of a kernel call. Counting boots where the press reached the title: before the fix 1 of 5 ran the loader; after it, 5 of 5. Three of the post-fix boots were driven far enough to classify the screen and all three reached the MAIN MENU, each with the same shape - title at 216-252s, 40 kernel calls by the loader, 6 ResolvePath reads. The failing boots before had zero of both, every time. Caveat kept in the doc: pre-fix runs were interleaved with compiles and a race is load-sensitive, so the counts corroborate the mechanism rather than carry it. Also fixes a self-inflicted confound. Two runs came back 'title_at_s=none' with the emulator log ending in 'Killed', which I first read as the title detector being too strict. It was not: an earlier copy of the script was still running because 'pkill -f resume_reliability.sh' had matched the shell running it rather than the script, and each of that copy's iterations kills the emulator BY NAME - outside run-canary's lockfile. The harness now takes its own lockfile and refuses a second copy, and the note records that pkill -f matches your own shell.
146 B
146 B
| 1 | run | title_at_s | thread_created | thread_ran_calls | resolvepath_after | screen |
|---|---|---|---|---|---|---|
| 2 | 1 | none | 0 | 0 | 0 | other |
| 3 | 2 | none | 0 | 0 | 0 | other |
| 4 | 3 | 216 | 1 | 40 | 6 | menu |
| 5 | 4 | 252 | 1 | 40 | 6 | menu |