Repository navigation
ci: keep the crash harness's host records on every run and free its memory first - #55
Merged
Merged
Conversation
…emory first The harness uploaded host.txt and the kernel log only when a job failed, so a green run left nothing to read a red one against. They are kept on every run now. The Gradle and Kotlin daemons the builds leave behind hold about 4.8 GB on the 16 GB runner while the emulator runs, so they are stopped before it starts, with free -m before and after in the log. The pin on emulator 37.1.11.0 stays. Its comment now records why: the 37.2.12.0 emulator process grows by 50 to 300 MB for every app launch until the runner is out of memory, and none of the three workarounds tried removed that. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XLy7TiPAxtVjPKEwQ9iwBa
stephane-segning
marked this pull request as ready for review
October 9, 2026 03:11
This was referenced Oct 9, 2026
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
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 this does
The crash harness stays on Android emulator 37.1.11.0 (build 15917651). Moving it to 37.2.12.0 (build 16428233) was tried three ways and none of them worked, so this PR only keeps what those attempts showed was worth keeping:
host.txtand the kernel log are uploaded on every run (if: always()), not only on a failure. A green run is what a red one is read against.free -mwent from 5757 MB used to 1120 MB used on this PR's own API 34 job, in the log).EMULATOR_BUILDrecords the cause.EMULATOR_BUILDitself is unchanged at "15917651", and the guard that readsPkg.BuildIdfrom the SDK's own record is unchanged.Why 37.2.12.0 cannot be adopted yet
The hang is host memory exhaustion, and the emulator process causes it. Its resident size grows with every app launch and never comes back:
-gpu guest, run 37873744804On 37.2.12.0 the growth is 50 to 300 MB per app launch, crashed or not: the release-build refusal phase, which never crashes anything, still grows by about 60 MB per launch. On 37.1.11.0 the same phases grow by 0 to 16 MB per launch after the first few. The sampler's
smaps_rollupshows the growth is anonymous native heap (Pss_Anon3.3 GB on 37.1.11.0, 8.0 to 8.4 GB on 37.2.12.0 at the end of API 30), on top of a fixed 2 GB guest RAM mapping. The AVD is already at the emulator's own 2560 MB minimum, so a lower AVD RAM changes nothing.The "hanging thread" watchdog, the QEMU stalls of 15 to 24 s and the lost runner are what the kernel does once physical memory and the 3 GB of swap are gone. Two 37.2.12.0 runs show it directly:
native: 20/20,native: 6/6,PASS release refuses the crash channel), then the runner received a shutdown signal during the finalflutter testGradle build, which is the last memory spike. That run's artifact was lost with the runner.detected a hanging thread 'QEMU2 main loop'(17.7 s),'QEMU2 CPU0 thread'(21.4 s) and'QEMU2 CPU1 thread'(22.8 s) were logged in that same final Gradle build, with 93 MB available.The three attempts, one change each, all measured on the same sampler:
-feature -Vulkan-gpu guestAPI 30 under the same workload (no 20-repeat stage) ends at 3.4 GB on 37.1.11.0 (run 37873735095) and at 8.0 to 8.6 GB on 37.2.12.0 in all three variants (runs 37871662706, 37873739944, 37873744804).
A green run on 37.2.12.0 here means the run finished before the memory ran out, by 93 to 468 MB. That is not a proof the harness works on it, so main stays pinned. Bump
EMULATOR_BUILDonce the emulator's size stays level inhost.txt.Verification
actionlint,zizmor --offline(no findings) andyamllint -d relaxedon.github/workflows/crash-harness.yml; Super-linter is green on the PR.@conventional-commits/parser0.4.1, assembled asci/commit-message-parse/parse.mjsassembles it, and thecommit-message-parsescheck passes.run:block, andpermissionsare unchanged.crash-harnessrun, 37875987419, on the pinned emulator: both jobs green. API 34 logsAndroid emulator version 37.1.11.0 (build_id 15917651), the guard printsPkg.BuildId=15917651,native: 20/20 runs passed,native: 6/6 runs passed,PASS release refuses the crash channel,1 test passed, and nohanging thread. The emulator stayed at 4.2 GB at most, 9502 MB of memory were available at the lowest, and swap was never used.host.txtwas uploaded by the green run, which is whatif: always()is for.🤖 Generated with Claude Code
https://claude.ai/code/session_01XLy7TiPAxtVjPKEwQ9iwBa
Generated by Claude Code