Skip to content

ci: bound the iOS leg's heaps (link out of process, 4 GB; Gradle 2 GB) and fix the watchdog's CPU arithmetic - #136

Merged
emooreatx merged 1 commit into
mainfrom
fix/ios-leg-oom
Sep 29, 2026
Merged

emooreatx merged 1 commit into
mainfrom
fix/ios-leg-oom

Conversation

@emooreatx

Copy link
Copy Markdown
Contributor

The v0.5.225 ios-xcframework leg died with GC overhead limit exceeded at 37 min on macos-14 (7 GB). Diagnosis from the KGP 2.0.21 jar: the Kotlin/Native release link runs inside the Gradle JVM by default, under gradle.properties' -Xmx8g — larger than the box. 0.5.224's 3 h 11 m (vs ~161 min measured) was already paging; 0.5.225 stopped fitting.

  • publish.yml: the iOS matrix entry passes --max-workers=1 -Dorg.gradle.jvmargs=-Xmx2g -Pkotlin.native.disableCompilerDaemon=true -Pkotlin.native.jvmArgs=-Xmx4g (the link gets its own bounded JVM; KGP's own out-of-process default is 3g). The -D outranks gradle.properties, so the desktop heap and the XCFramework cache key are untouched. Budget arithmetic and why -XX:-UseGCOverheadLimit is not a fix are in the matrix comment.
  • run_with_watchdog.sh: cpu_seconds returned a float on macOS, the $(( )) expansion errored on the first tick and killed the heartbeat subshell — the leg's last 33 minutes had no hang detection. Now integer (and the GNU dd- day prefix is handled), with --self-test (red on a copy with the fraction left in).
  • testing/test_publish_ios_leg.py (new, in build.yml's pytest list) pins the knobs, the heap budget, the unquoted splice, and the self-test.
  • AGENTS.md: one CI line; the build-locally-before-the-tag advice stays.

Not verifiable without a Mac: that the link's live set fits 4 GB. If not, the leg now fails in minutes with a known-heap OOM instead of after hours of paging; the remedy remains packaging/build_xcframework_local.sh before the tag. 84 tests pass; gates 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_0155SkTGdbwnSnR6tWBqJvUM

… integer

The v0.5.225 ios-xcframework leg died in linkReleaseFrameworkIosArm64 with
`GC overhead limit exceeded` after 37 min on macos-14 (3-core M1, 7 GB).
client/gradle.properties gives Gradle -Xmx8g, and KGP 2.0.21 runs the
Kotlin/Native release link INSIDE that JVM by default
(KotlinNativeToolRunner.runInProcess; kotlin.native.disableCompilerDaemon
flips it to javaexec). 0.5.224 had already taken 3h11m against ~161 min
measured, which is what paging looks like; two review batches later it
stopped fitting at all.

The bound lives on the leg's matrix entry, not in gradle.properties, which
is every desktop's setting and an input to the XCFramework cache key:

  --max-workers=1                            one link at a time
  -Dorg.gradle.jvmargs=-Xmx2g                Gradle only configures and waits
  -Pkotlin.native.disableCompilerDaemon=true the link gets its own JVM per task
  -Pkotlin.native.jvmArgs=-Xmx4g             KGP's default for it is 3g

4 GB is a budget for 7 GB (~1.3 OS/agent, <=2 Gradle, 4 link), not a
measurement; the comment says so, and says why -XX:-UseGCOverheadLimit is
not an answer. build_xcframework_local.sh is the desktop path and keeps the
desktop heap. Building locally before the tag is still the advice.

The watchdog on the same leg printed `line 108: 438.74: syntax error` on its
first heartbeat and then nothing: BSD ps prints CPU time with hundredths,
bash arithmetic rejects the sum, and an expansion error ends the subshell,
so the leg ran its last 33 minutes with no heartbeat and no hang detection.
cpu_seconds now drops the fraction per process (and handles the GNU day
prefix as days, not as another base-60 field) and prints with %d. A
--self-test feeds a fake BSD ps, including that exact 438.74, through the
same $(( cpu - last_cpu )); testing/test_publish_ios_leg.py runs it, proves
it goes red with the fraction left in, keeps the leg's two heaps summing
under the runner, and is wired into build.yml's pytest step.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155SkTGdbwnSnR6tWBqJvUM
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

@emooreatx
emooreatx merged commit 9a4a6a3 into main Sep 29, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant