test(host): the crash window's check runs through on Linux with g++ and clang #626
No reviewers
Labels
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
beanstalk: approved @ 1697603
beanstalk: approved @ 2c5a62e
beanstalk: approved @ 4fd82b7
beanstalk: approved @ 64d6d09
beanstalk: approved @ 6f91fae
beanstalk: approved @ 70a78f9
beanstalk: approved @ 8d361dc
beanstalk: approved @ 9d8356e
beanstalk: approved @ abf2227
beanstalk: approved @ d82f202
beanstalk: approved @ e5f1e40
beanstalk: approved @ ee8ab5f
ci: approved
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/macos
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
regression
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
ci: approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Longshot!626
Loading…
Reference in a new issue
No description provided.
Delete branch "zeldaootr/Longshot:fix-crash-dialog-check-fixture"
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?
Type: test · Risk: low · Tested on: Linux, no GPU (game-free check, g++ 13.3 and clang 23.1.5) · Needs: Windows, any GPU (game-free)
Why
tests/test_crash_dialog.pyhas failed onmainsince the crash window merged (#593): it never got past its own fixtures on Linux, somainis red before a release candidate and the crash window's real-run checks have not run at all. The crash window's code is right in everything the check reached once its fixtures were fixed. No open pull request or claim covers it.How to reproduce
Seen on: Linux (Ubuntu 24.04), no GPU; g++ 13.3 and clang 23.1.5
Settings and switches: none
Steps: on
mainaa95d35f, runpython -I -B tests/test_crash_dialog.py --cxx g++, then--cxx clang++Expected: every PASS line, through
PASS: Report: the clipboard's text has ...Actual: with g++:
AssertionErroratassert run(exe, "args", *good).strip() == "1|1234|..."(the fixture prints0|0||||NULL); with clang:clang++: error: '-x none' after last input file has no effect [-Werror,-Wunused-command-line-argument]building the fixtureWhat changed
Test-only, four faults of the check's own, each found once the one before it was out of the way. No product file changes, and every assertion is as it was.
argsandoptionsfixtures: they passedhos_crash_argsargv + 1, so the program-name slot held their own command word andargv[1]waslongshot: every helper command line read as the game's (0). They passargv + 2, asmainpasses its ownargv(host/hos_crash_dialog.c). (options, the settings file after the log, came with #729 and copied the sameargv + 1: with only theargsrepair the check stopped there, atrun(exe, "options", *good) == "1|NULL".)-x nonecame after the last input, an error under clang's-Werror; it is dropped. The real-run driver's four C files each get their own-x c: g++ applies a single-x cto the first file only and compiledhos_crash_dialog.cand the rest as C++ ('_Bool' was not declared)./dev/null.hos_crash_record_starttakes a regular file on stderr for the game's log (the game's own stderr is its log), so with the check's output in a file the helper looked for the run in that file, found no log, and the window named no stage (during the startmissing).out.txt; it is removed first, as the check already does elsewhere.Measurements
Verdict: passes: the check fails on
mainand passes on this branch, with g++ and with clang, in two interleaved rounds.Hardware: Linux (Ubuntu 24.04, kernel 6.8), x86-64, no GPU used; g++ 13.3.0, clang 23.1.5 (llvm-mingw's,
--target=x86_64-linux-gnu), Python 3.15Scene: no game: the game-free check, with its real helper runs against stand-in game processes
Method: the check run alone with
--cxx g++and with--cxx clang++, round 1 on main then this branch, round 2 the same again; failed runs per round (2 a round), and the PASS lines reachedHow to reproduce:
python -I -B tests/test_crash_dialog.py --cxx g++(and--cxx clang++) on each commit, its output to a fileaa95d35f89fd00f1Flags and settings
None
Testing
Tested: on Linux, the whole check with g++ and clang, failing on main
aa95d35fand passing here in two interleaved rounds, with its output both in a file and in the runner's pipe. The check has failed sincea0dac82e(#593's merge), the only commit that touched it,hos_crash_dialog.corhos_crash_dialog.h. The full suite (python -I -B tests/run_all.py, Linux, g++,LONGSHOT_VULKAN_HEADERSset) ran once onmainaa95d35fwith the other open fixes from the same sweep merged locally (ac6a1e97, not pushed, with this PR's head before the rebase,db15e4d5): 550 passed, 5 failed, 51 skipped. All five fail on cleanmainaa95d35ftoo:tests/test_make_game_cache.py,tests/test_options_budget_once.py,tests/test_mods_size_table.py,tests/test_walk_key.py, and this check, which there stopped at theoptionsfixture this rebase repairs; with it, the check passes whole (above).Not tested: Windows. There the check builds the same
argsfixture (theargv + 2and the dropped-x noneapply) and skips the real runs.Must be tested:
python -I -B tests/test_crash_dialog.py --cxx clang++, expecting every PASS line throughPASS: the issue link: ...and the note that the real helper runs are Linux only (by hand: any Windows contributor; or the Test Farm: @Beanstalk windows, run tests/test_crash_dialog.py)Risks
What could break: only this check.
Turning it off: revert the commit
Compatibility: Nothing changes
Checklist
Everyone
type(scope): description) of the status line's type.main.python -I -B tests/run_all.pypasses (any failure that also fails onmainis named).third_party/untouched (a new folder with aPROVENANCE.mdinstead).When it applies
Assisted-by:/Co-Authored-By:trailers.Rebased onto
mainaa95d35f(89fd00f1): #729 added anoptionsfixture to this check that copied the sameargv + 1, so with only theargsrepair the check stopped atrun(exe, "options", *good) == "1|NULL"; it now passesargv + 2too.The whole check passes again with g++ and clang (14 of 14 PASS lines, two interleaved rounds;
mainreaches 1).db15e4d5a189fd00f127View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.