[M1-HEAD-01] Fix macOS CI: platform-dependent zero-warn assertion in SecondRunFailsWithoutLogging - #33
Merged
Conversation
…SecondRunFailsWithoutLogging
The macos-arm64 and macos-intel jobs (merge matrix) are red on the
M1-HEAD-01 merge:
[ FAILED ] EngineRun.SecondRunFailsWithoutLogging
engine_tests.cpp:411: Expected equality of these values:
sink->entries.size() (Which is: 1) vs 0u
The test asserted zero Warn-or-above entries over the WHOLE capture
window - the first wall-clock-paced run_headless(1, 1) at 60 Hz (one
16.7 ms tick) plus the stopped-state second run. On a loaded runner a
frame can run longer than one tick of simulation time, and the loop
then warns loop/tick_dropped - the documented M1-LOOP-01 overload
behavior (the BoundedRun tests in the same suite deliberately do not
assert the drop count for this reason). The macOS runners' wall-clock
tail (measured in the same merge run: dropped=3 in BoundedRun,
dropped=2 in DoubleShutdownAfterRun) makes the warn near-certain
there, while the faster Linux runners happened to stay under the
16.7 ms frame - a wall-clock-dependent assertion that does not travel
across P0 platforms (the #20/#26/#28 CI-fix precedent).
The test's actual property is only about the SECOND run: a stopped-
state failure is a pure failure, no log (the GameLoop's moved-out
precedent). The assertion is now scoped to that run - the sink entry
count is recorded after the first run, and the second run must add
none. The first run's legitimate tick_dropped warn (its own
accounting, rate-limited per LOG-004) no longer taints the
stopped-state check.
No engine/loop code change: the second run still returns
InvalidArgument before any log call (engine.cpp run_headless,
stopped-state branch). Verified locally on the gcc and clang trees
(47/47 ctest, the EngineRun suite green).
Verified by this PR's ci:macos job (macos-arm64 + macos-intel).
The first pull_request event fired when the branch was pushed, before the PR existed and before the ci:macos label was attached, so that run's macOS jobs were skipped by the label selector. This empty commit re-fires the pull_request event with the label in place (the concurrency group cancels the label-less run).
offdev
added a commit
that referenced
this pull request
Sep 17, 2026
…tion; crash-handler write() under Release -Werror (#42) macOS (Intel + arm64) jobs: samples/hello/hello-baseline.cpp:179 — std::min(emitted, baseline_.size()) mixes std::uint64_t with std::size_t. On macOS uint64_t is unsigned long long and size_t is unsigned long, so the template deduction is a hard AppleClang error. On Linux/Windows the two types alias, which is why every other P0 job compiled the same source. Fix: cast the size_t operand to uint64_t so both arguments are one type on every platform. Determinism check job: src/laige-core/logging.cpp:500 — (void)write(...) does not suppress glibc's warn_unused_result (the attribute is attached under fortification, i.e. optimized builds), and the engine's -Werror makes it fatal. That is why only the job's Release g++ tree (build-det-release) failed while Debug g++ and every clang tree compiled the same TU. Fix: consume the result — the crash notice is best-effort and there is no async-signal-safe fallback if the write fails (LOG-007). Verification (local: g++ 16.2.1 / clang++ 22.1.8, x86-64 Linux): - logging.cpp compiles clean under -Wall -Werror in Debug, Release, and Release+_FORTIFY_SOURCE=2 (the CI trigger); hello sample TUs clean under all four compiler/flag sets. - Full ctest: 82/82 (incl. hello_baseline_fpx/fp32 + the mismatch/truncated/malformed/missing fixtures, replay and detcheck suites). - The CI detcheck flow reproduced end to end: four targeted builds (g++ Debug, clang++ Debug, clang++ Debug+ASan, g++ Release), reference-baseline sanity on both backends, synthetic self-check, and pairs A (g++ Debug vs clang++ Debug) and B (ASan Debug vs Release) on both backends — all result=OK ticks=301. - The macOS deduction error cannot be reproduced off-AppleClang (uint64_t == size_t on Linux/Windows); the P0 macOS jobs are the regression guard for it, as for the prior macOS CI fixes (#33, #35, #37, #39).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is broken
The
macos-arm64andmacos-inteljobs (merge matrix) are red on the M1-HEAD-01 merge (run 34958290344):Root cause
The test asserted zero Warn-or-above entries over the whole capture window — the first wall-clock-paced
run_headless(1, 1)at 60 Hz (one 16.7 ms tick) plus the stopped-state second run. On a loaded runner a frame can run longer than one tick of simulation time, and the loop then warnsloop/tick_dropped— the documented M1-LOOP-01 overload behavior (theBoundedRuntests in the same suite deliberately do not assert the drop count for this reason). The macOS runners' wall-clock tail (measured in the same merge run:dropped=3inBoundedRun,dropped=2inDoubleShutdownAfterRun) makes the warn near-certain there, while the faster Linux runners happened to stay under the 16.7 ms frame — a wall-clock-dependent assertion that does not travel across P0 platforms (the #20/#26/#28 CI-fix precedent).The fix
The test's actual property is only about the second run: a stopped-state failure is a pure failure, no log (the GameLoop's moved-out precedent). The assertion is now scoped to that run — the sink entry count is recorded after the first run, and the second run must add none. The first run's legitimate
tick_droppedwarn (its own accounting, rate-limited per LOG-004) no longer taints the stopped-state check.No engine/loop code change: the second run still returns
InvalidArgumentbefore any log call (engine.cpprun_headless, stopped-state branch).Verification
EngineRunsuite green).ci:macoslabel, so bothmacos-arm64andmacos-inteljobs run the exact failing suite.