Fix/ci platform flakes - #7
Conversation
…ng it a leak Growth past the allowance between the short and the long run is checked against a third run four times longer; a warm-up that has finished by the long run stops there, and only continued growth fails.
…hey are deterministic errors/c_stack.lua passes or fails on Windows depending on memory the runner can commit, and gc/finalize_after_return.lua depends on stack layout on macOS and Windows. Each now runs and must pass on the families where its answer is stable and is skipped elsewhere. git-bug: 4379825ab569b471e2c8f0c5e317cba2e0cfe506fa426a21795d52f76b3898eb git-bug: 18b4bab58c978c2adb03b1b309d4a8a8442d48673c30748f4dab02642669c873
A case that dies after printing the right output, as an abort at exit does, otherwise reports nothing that says why.
|
The runner discarded the child's stderr, so the abort's message is not in the log. 69e9ca8 makes a failing case show the last lines of its stderr; the run it triggers should name what aborts, and the fix follows from that. The other ten checks are green on 3b26b34 apart from macOS, still running. |
|
On 69e9ca8 Linux and macOS are green and With the Python abort on the two runs before, that makes two Windows-only faults, both only with the compile worker on: a value read as the wrong kind here, and a fast-fail 0xC0000409 (the code a stack-cookie check raises) after a function returning a tuple there. Neither is in code this PR touches, which changes test lists and test harnesses only, and no fix exists yet; the likely area is how the warm-up recompile and its callers agree on the Windows x64 ABI, which needs a Windows machine to pin down. Re-running the failed job once. |
1 participant
No description provided.