render --docker broken on Apple Silicon: Dockerfile.render installs unpinned Debian chromium; bookworm arm64 150.0.7871.46 SIGTRAPs at startup

[nshammas2025]

Bug: render --docker broken — Dockerfile.render installs unpinned Debian chromium, and the current bookworm arm64 package (150.0.7871.46) SIGTRAPs at startup

Summary

npx hyperframes render --docker fails 100% on an Apple Silicon Mac (Docker Desktop 29.6.1). The renderer image builds fine, but the bundled Chromium crashes with SIGTRAP (exit 133) at startup — before any capture — so the CLI reports the generic Failed to launch the browser process: Code: null and aborts in capture_streaming.

Root cause: Dockerfile.render installs Chromium unpinned (apt-get install chromium on debian:bookworm-slim). Debian's bookworm-security channel moved that package from 149.0.7827.196-1~deb12u1 (works) to 150.0.7871.46-1~deb12u1 (SIGTRAPs) around 2026-07-05/06. Any renderer image BUILT after that date carries the broken 150. Because the crash is in the Debian package, it is reproducible with zero hyperframes code.

The dbus/system_bus_socket errors in the CLI output are a red herring — non-fatal, present in working builds too; starting a dbus daemon does not change the crash.

Minimal repro (no hyperframes)

docker run --rm --platform linux/arm64 debian:bookworm-slim sh -c \
  'apt-get update -qq && apt-get install -y -qq chromium && \
   chromium --version && chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank; echo exit=$?'
# → Chromium 150.0.7871.46 built on Debian GNU/Linux 12 (bookworm)
# → exit=133   (128 + SIGTRAP)

Through the CLI: npx hyperframes render --docker --output ./out.mp4 --workers 1 on any project → same crash.

The A/B that isolates it (verified on this box)

Chromium (Debian bookworm arm64)	headless launch	source
149.0.7827.196-1~deb12u1	exit 0 (renders)	renderer images built ≤ 2026-07-05
150.0.7871.46-1~deb12u1	exit 133 (SIGTRAP)	renderer images built ≥ 2026-07-06, and plain debian:bookworm-slim today

Same VM, same kernel, same day — the ONLY variable is the Chromium package version. First-bad local renderer image: 0.7.37-arm64 (built 2026-07-06, chromium 150); last-good: 0.7.33-arm64 (built 2026-07-05, chromium 149). The CLI/version tag is NOT the variable — the image BUILD DATE (vs Debian's 149→150 publish) is.

Environment

• hyperframes CLI: 0.7.33 → 0.7.39 (the crash tracks the image's chromium, not the CLI version)
• Renderer image: hyperframes-renderer:<ver>-arm64, built locally by the CLI from the bundled Dockerfile.render (native linux/arm64, no emulation)
• Container: Docker Desktop LinuxKit, kernel 6.12.76-linuxkit, aarch64, PAGE_SIZE=4096
• Host: macOS (Darwin 25.3.0), Apple M4 Max; Docker Engine 29.6.1; VM backend = Apple Virtualization framework
• Host render (--no-docker, local chrome-headless-shell) works fine — the fault is isolated to the containerized Debian Chromium.

Ruled out (crash unchanged in every case)

--no-sandbox / --disable-setuid-sandbox; --security-opt seccomp=unconfined; a started system dbus; --single-process; --headless (old) vs --headless=new; --disable-gpu --disable-software-rasterizer --disable-dev-shm-usage --no-zygote --in-process-gpu --use-gl=disabled; --disable-crash-reporter --disable-breakpad --no-crashpad; --shm-size=2g present; native linux/arm64; PAGE_SIZE=4096.

It's the Debian arm64 BUILD, not "Chromium 150 vs this kernel"

chromedp/headless-shell:latest ships Chrome 150.0.7871.47 (essentially the same upstream Chromium as the crashing 150.0.7871.46) and launches + serves the DevTools/CDP endpoint fine on the identical VM/kernel. So upstream Chromium 150 is healthy here; the SIGTRAP is specific to Debian's bookworm arm64 package build. (There is Debian precedent for arm64-specific chromium regressions, e.g. Bug#1088974 "stack smashing detected" on chromium 131 arm64.)

Requested fix

1. Pin the Chromium version in Dockerfile.render (or switch to a non-Debian arm64 Chromium — Playwright ships a linux-arm64 build; chrome-headless-shell is linux64-only per the Dockerfile's own comment), so an image build can't silently pick up a broken security update.
2. Add an escape hatch — a custom-image-tag override and/or a browser executable-path / launch-flag passthrough — so users can select a known-good Chromium without a CLI patch. (Today the only override is HYPERFRAMES_DOCKER_PLATFORM. ensureDockerImage uses a cached image tag when present and only builds when the tag is absent, so a machine with a cached pre-2026-07-06 image keeps rendering — but any cold-cache build, docker rmi, or system prune silently re-pulls the broken 150, and there is no supported way to force a pinned Chromium.)
3. Surface the child's real exit signal (SIGTRAP / exit 133) instead of the generic Failed to launch the browser process: Code: null — it would have pointed straight at the crashing binary.

Scope note

Untested whether Debian bookworm chromium 150 arm64 also SIGTRAPs on native (non-LinuxKit) arm64 Linux — a maintainer on real arm64 hardware may not reproduce the crash itself, but the debian:bookworm-slim one-liner above should reproduce under Docker Desktop-class conditions. Worth a parallel report to the Debian chromium package (no existing bug for 150.0.7871.46 found).