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.
6 lines
146 B
CSV
6 lines
146 B
CSV
run,title_at_s,thread_created,thread_ran_calls,resolvepath_after,screen
|
|
1,none,0,0,0,other
|
|
2,none,0,0,0,other
|
|
3,216,1,40,6,menu
|
|
4,252,1,40,6,menu
|