mirror of
https://github.com/hanzoai/frames.git
synced 2026-09-24 00:08:03 +00:00
Via
a80c8a533a
Field feedback (#hyperframes-cli-feedback ts=1784227832, darwin/x64, macOS 12, HyperFrames CLI 0.7.60) hit `dyld: Symbol not found: _kVTCompressionPropertyKey_ReferenceBufferCount` from VideoToolbox when launching the pinned chrome-headless-shell mac-152.0.7928.2. The symbol is macOS-13-only, so older hosts abort the binary at dyld load before any browser process starts. The reporter recovered by installing an older shell (`@puppeteer/browsers install chrome-headless-shell@150`) and pointing `PRODUCER_HEADLESS_SHELL_PATH` at it. Their check/snapshot commands accepted that older cached shell (they do not force the pinned build), but the render command requires v152 via `preferManagedChrome: true` and could not fall back on its own. The generic "Try --docker" hint didn't name any of the browser-path env vars. Sibling failure mode to the download-time hint added in #2443 and the closed-with-invite #2078 (SIGTRAP at launch on macOS arm64), and the in-flight #2481 (Windows STATUS_STACK_BUFFER_OVERRUN); same `HYPERFRAMES_BROWSER_PATH` remediation, different trigger + platform. The match is gated on: 1. Puppeteer launch-failure wrapper text 2. dyld Symbol-not-found signal 3. a macOS-13-only symbol OR the VideoToolbox framework so unrelated darwin launch failures do not mis-fire the hint. The symbol name is macOS-version-specific by construction — if a user's dyld cannot find `_kVTCompressionPropertyKey_ReferenceBufferCount` their host is <13, no separate `os.release()` gate needed. - Signed-off-by: Via -