Split out of #554, whose "suggested next steps" recommended adding lang_test.py to the aarch64 job. That recommendation is weaker than it looks and should not be adopted as written.
Why the obvious guard would not have worked
#554 was a hang in orlyc's embedded server on aarch64, fixed in #555. It reproduces only in a release build:
|
result |
jhm -c release orlyc, arm |
wedged on the first attempt, 3 out of 3 |
jhm -c debug orlyc, arm |
15 runs, all clean |
The arm64-build job in ci.yml builds debug. Adding lang_test.py there would have extended the job and caught nothing.
That is not a coincidence of timing: the bug was the optimiser hoisting a thread-pointer read out of a loop, which -O0 does not do. A whole class of arm-specific defects will behave the same way.
What the guard should be
Compile one package with a release orlyc on an ubuntu-24.04-arm runner, with a deadline and a stack dump on expiry. The workflow already exists — .github/workflows/orlyc-arm-repro.yml on the feat/548-multiarch-image branch — and takes about nine minutes: it builds the orly/orlyc target alone rather than the whole tree, so it never pays for the full-tree LTO link that made the arm docker image job time out (#552).
Shape:
jhm -c release orly/orlyc on arm (target alone, not make release)- run it on one package with a timeout
- on expiry, capture per-thread state and backtraces and fail
Open questions worth deciding when this is picked up:
- Gate or informational?
arm64-build is continue-on-error today because aarch64 is "known to work, not yet released against". This one has a specific, now-understood failure mode, so it is a better gate candidate than the general build job.
- Does it belong as a step in
arm64-build or as its own job? Its own job parallelises, but pays the toolchain install twice.
timeout cannot kill orlyc with SIGTERM — RunUntilCtrlC masks every signal except SIGINT — so use timeout -s KILL, or the step hangs instead of failing.
Not urgent
#555 fixes the defect; this is about noticing the next one. Worth doing before aarch64 is promoted from "known to work" to supported, and before the multi-arch image in #552 ships.
Split out of #554, whose "suggested next steps" recommended adding
lang_test.pyto the aarch64 job. That recommendation is weaker than it looks and should not be adopted as written.Why the obvious guard would not have worked
#554 was a hang in
orlyc's embedded server on aarch64, fixed in #555. It reproduces only in a release build:jhm -c releaseorlyc, armjhm -c debugorlyc, armThe
arm64-buildjob inci.ymlbuilds debug. Addinglang_test.pythere would have extended the job and caught nothing.That is not a coincidence of timing: the bug was the optimiser hoisting a thread-pointer read out of a loop, which
-O0does not do. A whole class of arm-specific defects will behave the same way.What the guard should be
Compile one package with a release
orlycon anubuntu-24.04-armrunner, with a deadline and a stack dump on expiry. The workflow already exists —.github/workflows/orlyc-arm-repro.ymlon thefeat/548-multiarch-imagebranch — and takes about nine minutes: it builds theorly/orlyctarget alone rather than the whole tree, so it never pays for the full-tree LTO link that made the arm docker image job time out (#552).Shape:
jhm -c release orly/orlycon arm (target alone, notmake release)Open questions worth deciding when this is picked up:
arm64-buildiscontinue-on-errortoday because aarch64 is "known to work, not yet released against". This one has a specific, now-understood failure mode, so it is a better gate candidate than the general build job.arm64-buildor as its own job? Its own job parallelises, but pays the toolchain install twice.timeoutcannot killorlycwithSIGTERM—RunUntilCtrlCmasks every signal exceptSIGINT— so usetimeout -s KILL, or the step hangs instead of failing.Not urgent
#555 fixes the defect; this is about noticing the next one. Worth doing before aarch64 is promoted from "known to work" to supported, and before the multi-arch image in #552 ships.