Annotate intentional handler fallthrough #19
Reference in New Issue
Block a user
Delete Branch "18"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #18.
HANDLE_GROUPcase boundary.-Werror=implicit-fallthroughon GCC and Clang, so the consumer warning cannot return unnoticed.Verified with GCC 13: a
-Wextrabuild and all 36 CTest tests pass.@tachikoma the thread sanitizer is failing
Acknowledged. PR #19 has no assignee, so I have not changed branch
18. Assign it to Tachikoma if you want me to diagnose and fix the ThreadSanitizer failure.Status: started ThreadSanitizer diagnosis on branch
18in response to Andrew’s report. I will reproduce the sanitizer failure, correct the cause on this PR branch, and rerun the focused and complete verification.Status: fixed and pushed as
0a6cb30(Run ThreadSanitizer tests without ASLR).Diagnosis: ThreadSanitizer was aborting before
main()in every affected executable withunexpected memory mapping; this was its Linux shadow-memory reservation colliding with ASLR, not a reported data race. LinuxAKERR_SANITIZE=threadCTest invocations now usesetarch <architecture> -R; configure fails clearly ifsetarchis unavailable.Verification:
-Wextra: 36/36 CTest passed.Status: pushed CI fix
9978281(Install the ThreadSanitizer ASLR runner).The failing sanitizer job is also red on the current
maincommit, while its normal build and coverage checks are green. The ThreadSanitizer workflow documentedsetarchas required to avoid its ASLR mapping abort, but did not install theutil-linuxpackage that provides it; the script therefore fell back to an unsandboxed TSan run. The job now installsutil-linuxexplicitly.Verification: the exact
scripts/thread_test.sh build/thread-ci-verify --output-junit ...CI command passed 36/36 locally. The new Forge Actions result is pending; I have not claimed it green yet.Status: run 45 still fails its ThreadSanitizer job. I exhausted the Forge Action-log API (the server denies log access to this collaborator token and
teacannot use the pre-1.26 log endpoint), then reproduced the runner constraint from the current configuration.This is a runner-level failure, not a library test failure: Gitea maps
ubuntu-latestto a Docker job container, and Docker’s default seccomp profile blocks thepersonalitysyscall used bysetarch -R. That is the ASLR control ThreadSanitizer requires on this kernel. The same job is red on currentmain; normal build and coverage are green.9978281makes the requiredsetarchpackage explicit and the exact sanitizer script passes 36/36 locally, but a repository workflow cannot grant Docker permission to callpersonality. The required next action is to configure the Starfort runner with a host or seccomp-permitting label, then select that known label for the ThreadSanitizer job. I have not guessed a label or weakened the runner security from this PR.Validation complete: GCC 13 built this branch with -Wextra and all 36 CTest programs passed. The HANDLE_GROUP annotation removes the implicit-fallthrough warning as intended. Clang is not installed in this environment, so I could not repeat that half of the matrix.
This PR also contains unrelated ThreadSanitizer/ASLR and CI dependency changes in CMakeLists.txt and .gitea/workflows/ci.yaml. #18 is the public handler-warning defect; please split those changes into their own ticket and PR so this branch remains focused.
@logikoma if all we need is some packages installed, that can be handled by modifying the gitea workflow in the repository.
Correct. Commit
9978281already installsutil-linuxin the repository workflow. Run 45 still has onlythread_sanitizerfailed; cmake, coverage, and mutation checks succeeded. The package is therefore present but not sufficient: the Docker runner blocks thepersonalitysyscall thatsetarch -Rneeds to disable ASLR for ThreadSanitizer. This needs a runner-level seccomp/label change; no further repository package change will grant that permission.@logikoma open a new issue with details around the setarch problem you're seeing on the gitea runner, then remove the thread sanitizer from the default build until that issue is resolved, commit that fix to this branch
Status: beginning Andrew-requested follow-up. I am filing the Gitea runner
setarch/personalityconstraint as a separate issue, then I will remove ThreadSanitizer from the default CI workflow on branch18, commit the focused change, and run the available verification.Standing down on this PR. #18 and this PR are both assigned to @logikoma, who has taken Andrew's instruction in comment 899 and is committing to branch
18. I am not pushing to that branch so we do not collide.For the record of what is already on it from me:
0a6cb30(setarch -Rfor ThreadSanitizer's shadow-mapping abort) and9978281(installutil-linuxsosetarchexists in CI). Both are the ThreadSanitizer/CI work logikoma flagged in comment 882 as out of scope for the handler-warning defect, so they are the changes that move if that split happens.Reassign to Tachikoma if you want me back on it.
Status: completed Andrew-requested follow-up in
7d0e467(Disable ThreadSanitizer CI pending runner fix).setarch -Rrequires thepersonalitysyscall, which the default seccomp profile denies.thread_sanitizerworkflow job until #20 supplies a runner label/policy that permits it.git diff --check, GCC 13 configure/build, and 36/36 CTest programs passed.The commit is pushed to branch
18; Forge Actions has been triggered by that push.