Skip to content

Flaky: SimCameraHelper shm probe — helper exits with a signal during shutdown (bisected to 14ad57f) #143

Description

@kleyson

Summary

SimCameraHelper shm probe > shutdown unmaps shm so a fresh shm_open returns -1 (ENOENT) is flaky on main, failing roughly 1 run in 4 locally and more often on a loaded CI runner. Bisected to 14ad57f ("Harden helper shutdown and HID log timing").

The helper is killed by a signal instead of exiting 0 during shutdown, so the test's own guard fires:

error: helper exited with null (expected 0)
helper stderr (last 600 chars):
[serve-sim-camera] shm "/sscam-tst-xdmt4g1drv" + 4 IOSurfaces (1280x720 BGRA)
[serve-sim-camera] placeholder source running @ 30fps (1280x720, first frame seq=1)
[serve-sim-camera] control socket /tmp/sscam-tst-xdmt4g1drv.sock
[serve-sim-camera] running — Ctrl+C to stop
[serve-sim-camera] placeholder source running @ 30fps (1280x720, first frame seq=6)
[serve-sim-camera] placeholder source running @ 30fps (1280x720, first frame seq=7)

  at packages/serve-sim/src/__tests__/shm-probe.integration.test.ts:407:17

Note it is the exitCode !== 0 branch that throws, not the shm_open assertion — the shm name is unlinked fine. The helper dies on the way out.

Reproduction

bun run packages/serve-sim/build.ts
bun test --max-concurrency=1 packages/serve-sim/src/__tests__/shm-probe.integration.test.ts

Run it 8–10 times; it fails intermittently. A rebuilt helper is required — a stale dist/simcam/serve-sim-camera-helper invalidates the result.

Bisect

Pristine checkouts, rebuilt each time, 8–10 consecutive runs of the command above:

commit result
7f109fb — ci: pin bun version via .bun-version (#133) 8/8 pass
14ad57f — Harden helper shutdown and HID log timing 2/10 fail
39958d0 — restore Xcode 27 Device Hub streaming and input (#140) 2/8 fail

7f109fb is the parent of 14ad57f, so the change in between is the trigger.

Not the bun version

Worth stating because it is the obvious first guess: it is not a bun regression. The same command fails identically under 1.3.14 (the pinned version) and 1.4.0, at the same rate.

It is also concurrency-shaped — with default concurrency (bun test across the whole repo) it passes far more often than with --max-concurrency=1, which is what CI uses.

Environment

  • macOS 26.6.2, arm64 (Apple silicon)
  • bun 1.3.14 (pinned) and 1.4.0, both affected
  • Also reproduced on GitHub Actions macos-latest, where the rate is high enough that two consecutive attempts both failed

Why it matters

--max-concurrency=1 over packages/serve-sim/src/__tests__/ is the command in CI, so this intermittently reddens builds for a fault unrelated to the change under test. Happy to test a patch against the same 10-run loop if that helps.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions