- the arming case read the ambient lane's MOBILEGL_LOG_FILE_PATH, and that log is
opened fopen(path, "w") by every process in the lane: with 406 entries per backend
and CI running them -j 4, a whole-file read races a neighbour's bring-up, and the
file that survives the lane holds only the LAST writer. Every other log-reading
scenario in this suite (UnlocatedIoBlocks, the primgen reroute, the point-size
demotion) is registered in a filtered lane with its own log for exactly that reason;
PipeVerifyArmingScenario.Armed now follows them, in DirectGLES.VerifyArming. /
DirectVulkan.VerifyArming., and skips anywhere MGITEST_PIPE_ARMING_LANE is unset
- what that can prove is written down where it is asserted: arming is a property of
(this library, this environment) and these two processes share both with their ~400
ambient siblings. A per-process census is not available through a shared log, and a
comment that claimed one was the reason CI grepped a file that could not answer
- the re-exec'd poison child ran RunSequence() and then _exit(0) unconditionally, so a
fatal assertion inside it - the shader failing to compile, say - returned before the
draw and the glGenerateMipmap and still reported success: WithoutOmissionCompletes,
the one green entry negative control B turns red, passed on a child that ran none of
the sequence. It now exits HasFailure() ? 1 : 0, and checks glGetError() after the
mipmap so a rejected sequence is part of the answer rather than stderr nobody reads