ci: add debug workflow with -finit-real=snan + fcheck=all#136
Closed
k-yoshimi wants to merge 3 commits into
Closed
ci: add debug workflow with -finit-real=snan + fcheck=all#136k-yoshimi wants to merge 3 commits into
k-yoshimi wants to merge 3 commits into
Conversation
Diagnostic workflow that builds libXapi.so with gfortran runtime traps enabled and runs the tests that currently SIGABRT/SEGV in the release CI. The goal is to surface uninit-read / array-bounds violations with clean backtraces so they can be fixed one at a time. Key flags (overriding OFLAGS so everything built with $(OFLAGS) inherits them): -fbounds-check -fcheck=all -ffpe-trap=invalid,zero,overflow -fbacktrace -finit-real=snan (read-before-write -> FPE trap) -finit-integer=-8888 (obvious sentinel) -finit-logical=false -finit-derived (recursively init derived-type members) -O0 -g (no optimization, full debug symbols) Trigger model: - workflow_dispatch: manual run from the Actions tab - pull_request labeled 'debug-ci': apply the label to a PR for a one-shot diagnostic run The pytest step sets continue-on-error=true and uploads the log as an artifact — the whole point is to capture crash backtraces, not to green-check. Phase 1 of the post-#135 followup plan discussed with user: diagnose -> fix -> land per-bug PRs until the release CI can run the full test suite without --deselect. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Owner
Author
|
@cursor review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Owner
Author
|
@cursor review |
Bugbot caught that `2>&1 | tee pytest-debug.log` swallows pytest's exit code (pipeline defaults to tee's 0), making continue-on-error dead — the step always showed green in the UI even when every test crashed. `set -o pipefail` + explicit `shell: bash` fixes that so Actions displays red when pytest exited non-zero, even while the job itself continues to subsequent steps (the `continue-on-error: true` contract). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 42f0748. Configure here.
| # way a fresh run is visually distinguishable from one where | ||
| # everything crashed cleanly. `set -o pipefail` ensures the | ||
| # `| tee` does not swallow pytest's exit code. | ||
| continue-on-error: true |
There was a problem hiding this comment.
continue-on-error contradicts stated goal of red status
Medium Severity
The step-level continue-on-error: true forces the overall job status to green/success in the Actions UI, directly contradicting the comment that says "the Actions UI shows red" and the PR description stating "Forcing green status would defeat the purpose." The if: always() on the upload step already ensures the artifact is uploaded after a failure, making continue-on-error: true both redundant and counterproductive — it hides the very crashes this workflow exists to surface.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 42f0748. Configure here.
Bugbot caught that step-level `continue-on-error: true` always produces a green step status, directly contradicting the comment and the PR description. The artifact upload has its own `if: always()` guard, so removing `continue-on-error` does not lose logs on failure — it just makes the Actions UI honestly show red when pytest exits non-zero, which is the entire point of the workflow. `set -o pipefail` stays (so `| tee` does not swallow pytest's exit code before it reaches the job status). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
k-yoshimi
added
the
debug-ci
6 tasks
k-yoshimi
added a commit
that referenced
this pull request
Apr 20, 2026
Hypothesis test for the SIGABRT class tracked in docker/ci-repro/ and in the --deselect list in the release CI: on the developer host (gfortran 13.3.0) the tests pass; in CI (gfortran 13.2.0, the Ubuntu 24.04 default) a subset SIGABRTs inside the Fortran finalize path. 14.x is the closest widely-available bump and, if the problem is a 13.2-specific codegen / runtime bug, should make it disappear. Pulls gfortran-14 from `ppa:ubuntu-toolchain-r/test`, points /usr/bin/gfortran via update-alternatives so every module Makefile picks it up without per-file patches. If this turns CI green with the --deselect list relaxed, the SIGABRT was a 13.2 regression. If not, the Docker repro path (#137) + debug workflow (#136) remain the way forward. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Owner
Author
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.
Summary
Diagnostic CI workflow to surface the SIGABRT / SEGV crashes that the release CI (#135) currently skips. Build each `libapi.so` with gfortran runtime traps + signaling-NaN initialization, then run the full test suite with `--forked`. Log is uploaded as an artifact.
Phase 1 of the post-#135 follow-up plan discussed with user:
diagnose → fix → land per-bug PRs until release CI can run the full test suite without `--deselect`.
Key gfortran flags
```
OFLAGS = -g -O0 -m64 -std=legacy \
-fbounds-check -fcheck=all \
-ffpe-trap=invalid,zero,overflow -fbacktrace \
-finit-real=snan # read uninit real -> FPE trap
-finit-integer=-8888 # obvious sentinel
-finit-logical=false
-finit-derived # recursively init derived-type members
```
Trigger model
Why `continue-on-error: true`
The whole point is to SURFACE crashes. Forcing green status would defeat the purpose. The step uploads `pytest-debug.log` as an artifact so backtraces are reviewable from the Actions UI.
Follow-up flow after merge
Test plan
🤖 Generated with Claude Code
Note
Low Risk
Low risk: it only adds a new, explicitly triggered CI workflow and does not affect the existing release
python-testsjob or production code paths.Overview
Adds a new opt-in
python-tests-debugGitHub Actions workflow that can be triggered manually or by applying adebug-cilabel to a PR.The job builds the Fortran module
.solibraries using strict gfortran debug/runtime-trap flags (e.g., bounds checking,-fcheck=all,-finit-*=snan, FPE traps) and runs the full pytest suite with--forked, teeing output topytest-debug.logand uploading it as an artifact for post-crash backtrace inspection.Reviewed by Cursor Bugbot for commit 42f0748. Bugbot is set up for automated code reviews on this repo. Configure here.