How to capture diagnostics for bundled Chrome 152.0.7977.30 SIGTRAPs on Linux x86_64? #3885

I am trying to turn a retained HyperFrames headless-browser crash cluster into a useful reproducible bug report. I do not yet have a shareable minimal composition or the original render stderr, so I am asking here rather than claiming a reproducible upstream bug.

Recorded failure

On September 10, 2026 between 23:35 and 23:43 UTC+03, systemd recorded eleven cores from HyperFrames' bundled headless Chrome 152.0.7977.30. Renderer processes received SIGTRAP, including compositor and foreground thread-pool threads. Several records share executable offset 0x73fb6d8.

The executable is stripped. Local symbolization did not resolve the function, and its matching headless_shell.debug file was unavailable. The exact assertion remains unknown. The inspected journal records did not include a fatal assertion, thread-creation failure or OOM explanation.

Recorded launch arguments include:

--enable-unsafe-webgpu
--force-gpu-mem-available-mb=16384
--no-sandbox
--disable-dev-shm-usage

None of these flags is established as the cause. The memory override does not mean each process allocated 16 GiB.

Environment and limits

• Arch Linux with Omarchy 4.0.2; x86_64.
• Running kernel during the cluster: 7.1.8-arch1-3.
• Ryzen AI 9 HX 370 / Radeon 890M; approximately 60 GiB usable RAM.
• Installed Mesa and Vulkan Radeon 26.2.1; AMD firmware package 20260810-2.
• Hyprland 0.56.2 / Wayland desktop; the affected browser processes were headless.
• Exact HyperFrames CLI version, composition, command and worker count for the failing invocations were not recovered. I have not established reproduction on the latest CLI.
• Other browser automation was active that evening. Individual historical process-group memory peaks are not a simultaneous memory total.
• Journald recorded memory pressure later, at 23:53. No accompanying OOM kill was found. A causal link to these SIGTRAPs is unproven.

Help requested

Is matching debug information available for the bundled Chrome version above, or is there a supported way to capture its fatal assertion and symbolized stack during a render? What is the recommended way to retain complete browser stderr and actual worker count for a single-worker attempt before comparing the original concurrency?

I understand the bug template requires a public minimal reproduction. The next step would be to capture these diagnostics and reduce the input before filing a bug. No raw core, private composition or browser profile is attached.