Following up with precise forensic data to assist with diagnostics.
To clarify the environment parameters: this is running as a native arm64 binary
on an arm64 host (no Rosetta/QEMU translation layer in play). Additionally, the
crash triggers identically even when executed with `--no-sandbox`,
`--privileged`, and `seccomp=unconfined`, ruling out standard runtime sandbox
boundary restrictions.
Attached/Belowis the verbose crash log / gdb backtrace showing exactly where
the SIGTRAP fires during execution:
CRASH FORENSICS — chromium 150.0.7871.46 (trixie-security) under Docker Desktop
on macOS/arm64
Prepared 2026-07-06 · supplement to the Debian bug report (chromium, severity:
important)
================================================================================
1. SUMMARY
================================================================================
chromium 150.0.7871.46-1~deb13u1 (from trixie-security) crashes on launch with
SIGTRAP (shell exit code 133 = 128+5) when run headless inside a linux/arm64
container under Docker Desktop for Mac. The fatal signal is received by the
MAIN BROWSER PROCESS (gdb Thread 1), not a sandboxed child, late in startup —
after the GPU process, storage service, and network service have all spawned
successfully. On aarch64 release builds a SIGTRAP at a code address is the
signature of Chromium's IMMEDIATE_CRASH() macro (a compiled-in brk instruction
emitted for a failed internal CHECK), so this looks like a release-build CHECK
failure specific to this environment, not memory corruption.
chromium 147.0.7727.137-1~deb13u1 (plain trixie) works flawlessly in the
IDENTICAL container. So does Chromium 148 (Playwright's build). The regression
is specific to the 147 -> 150 jump as packaged for arm64.
================================================================================
2. ENVIRONMENT
================================================================================
Host: macOS 26.5.1 (build 25F80), Apple Silicon (arm64)
Docker: Docker Desktop, engine 29.6.1 (linux/arm64)
VM kernel: 6.12.76-linuxkit #1 SMP Thu Jun 18 21:12:39 UTC 2026 aarch64
Page size: 4096 (rules out the known 16K-page aarch64 chromium bugs,
e.g. https://issues.chromium.org/issues/40257452)
Container: pristine debian:trixie (docker.io library image), nothing
installed except chromium + deps via apt
Memory/CPU: 7.9 GB / 12 cores available to the VM (not resource-starved)
Architecture: native arm64 end to end — NO Rosetta/QEMU instruction
translation involved
================================================================================
3. RESULT MATRIX (all in identical pristine debian:trixie containers)
================================================================================
Command under test:
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
| build | source | result |
|-----------------------------------------|-------------------|---------------|
| 147.0.7727.137-1~deb13u1 | trixie (plain) | exit 0, DOM OK|
| 150.0.7871.46-1~deb13u1 | trixie-security | exit 133 |
| 148.0.7778.0 (Playwright chromium-1223) | playwright.dev | exit 0, DOM OK|
Isolation variants tested against 150 — ALL crash identically (exit 133):
- default Docker seccomp profile
- --security-opt seccomp=unconfined
- --privileged
- flag combinations: --disable-dev-shm-usage, --disable-crashpad,
--no-zygote, --single-process (individually and combined)
The seccomp/privileged results argue AGAINST a sandbox-validation or
syscall-filtering mechanism: relaxing all confinement changes nothing.
================================================================================
4. VERBOSE STDERR — TAIL BEFORE DEATH
================================================================================
(chromium --headless=new --no-sandbox --disable-gpu --enable-logging=stderr
--v=1 --dump-dom about:blank ; last lines, PIDs from the recorded run)
[2567:2567:...] WARNING:sandbox/policy/linux/sandbox_linux.cc:405]
InitializeSandbox() called with multiple threads in process gpu-process.
[2526:2553:...] ERROR:dbus/bus.cc:405] Failed to connect to the bus: Could not
parse server address: Unknown address type ...
[2526:2526:...]
VERBOSE1:components/proxy_config/pref_proxy_config_tracker_impl.cc:462] set
chrome proxy config service ...
[2526:2526:...]
VERBOSE1:components/signin/core/browser/account_reconcilor.cc:254]
AccountReconcilor::RegisterWithIdentityManager
[0706/131945.241897:ERROR:third_party/crashpad/crashpad/util/file/file_io_posix.cc:145]
open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or
directory (2)
[0706/131945.241954:ERROR:third_party/crashpad/crashpad/util/file/file_io_posix.cc:145]
open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or
directory (2)
exit: 133
Notes:
- No FATAL log line is emitted before the trap.
- The crashpad cpufreq errors are the crash HANDLER annotating the already-
in-flight crash (linuxkit exposes no cpufreq sysfs); they are a symptom
marker, not the cause.
- The dbus errors are environmental noise: the WORKING 147 and 148 runs
print the same dbus errors and render fine.
- Startup gets far: GPU process, storage service, network service, disk
cache, and profile init all complete before the trap.
================================================================================
5. GDB — FATAL SIGNAL CAPTURE (default multi-process mode)
================================================================================
gdb -q -batch -ex "handle SIGTRAP stop" -ex run -ex bt \
--args /usr/lib/chromium/chromium --headless=new --no-sandbox --disable-gpu
--dump-dom about:blank
Thread 1 "chromium" received signal SIGTRAP, Trace/breakpoint trap.
0x0000aaaac831bb9c in ?? ()
#0 0x0000aaaac831bb9c in ?? ()
#1 0x0000002c007029b8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Notes:
- The trap lands on THREAD 1 OF THE BROWSER PROCESS (not a renderer/child).
- Frame #0 is inside the main chromium text segment (0xaaaa... is the
executable's mapping base on this kernel); the binary is stripped, so no
symbol names without chromium-dbgsym. Happy to re-run with dbgsym from
debian-debug on request for a named backtrace.
- Frame #1's address (0x2c007029b8) sits outside normal library mappings,
consistent with a V8/JIT-region or pointer-compression-cage address —
or simply with IMMEDIATE_CRASH() leaving no unwindable caller frame.
- aarch64 IMMEDIATE_CRASH() compiles to a brk instruction, which raises
exactly this: SIGTRAP with no core-dumping signal and no FATAL log.
================================================================================
6. REPRODUCTION (from any Apple Silicon Mac with Docker Desktop)
================================================================================
# broken build (trixie-security):
docker run --rm debian:trixie bash -c '
apt-get update -qq && apt-get install -y -qq --no-install-recommends chromium
chromium --version
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
echo "exit: $?"'
# -> Chromium 150.0.7871.46 ... exit: 133, no DOM output
# control (plain trixie, same container recipe):
docker run --rm debian:trixie bash -c '
apt-get update -qq && apt-get install -y -qq --no-install-recommends \
chromium=147.0.7727.137-1~deb13u1 chromium-common=147.0.7727.137-1~deb13u1 \
chromium-sandbox=147.0.7727.137-1~deb13u1
chromium --version
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
echo "exit: $?"'
# -> Chromium 147.0.7727.137 ... <html>...</html> exit: 0
================================================================================
7. WHAT THE EVIDENCE SUPPORTS (and what it rules out)
================================================================================
Supported:
- A regression introduced between 147.0.7727.137 and 150.0.7871.46 as built
for Debian arm64, manifesting as a release-build CHECK / IMMEDIATE_CRASH
in the browser process under the linuxkit 6.12 VM kernel.
Ruled out by direct test:
- Container/image configuration (pristine debian:trixie reproduces it)
- seccomp filtering (unconfined crashes identically)
- Privilege/capability restrictions (--privileged crashes identically)
- 16K page size (this VM uses 4K pages)
- dbus absence, /dev/shm size, crashpad, zygote, process model (all varied,
no effect)
- Instruction translation (native arm64 host and image; no Rosetta/QEMU)
Unknown (needs symbols or upstream knowledge):
- The specific CHECK that fires. A dbgsym-resolved backtrace can be
provided on request.
Workaround in production use: pin the test-bed browser to Playwright's
chromium distribution and treat apt chromium purely as a shared-library
donor. Bare-metal/native-Linux users appear unaffected.
CRASH FORENSICS â chromium 150.0.7871.46 (trixie-security) under Docker
Desktop on macOS/arm64
Prepared 2026-07-06 · supplement to the Debian bug report (chromium, severity:
important)
================================================================================
1. SUMMARY
================================================================================
chromium 150.0.7871.46-1~deb13u1 (from trixie-security) crashes on launch with
SIGTRAP (shell exit code 133 = 128+5) when run headless inside a linux/arm64
container under Docker Desktop for Mac. The fatal signal is received by the
MAIN BROWSER PROCESS (gdb Thread 1), not a sandboxed child, late in startup â
after the GPU process, storage service, and network service have all spawned
successfully. On aarch64 release builds a SIGTRAP at a code address is the
signature of Chromium's IMMEDIATE_CRASH() macro (a compiled-in brk instruction
emitted for a failed internal CHECK), so this looks like a release-build CHECK
failure specific to this environment, not memory corruption.
chromium 147.0.7727.137-1~deb13u1 (plain trixie) works flawlessly in the
IDENTICAL container. So does Chromium 148 (Playwright's build). The regression
is specific to the 147 -> 150 jump as packaged for arm64.
================================================================================
2. ENVIRONMENT
================================================================================
Host: macOS 26.5.1 (build 25F80), Apple Silicon (arm64)
Docker: Docker Desktop, engine 29.6.1 (linux/arm64)
VM kernel: 6.12.76-linuxkit #1 SMP Thu Jun 18 21:12:39 UTC 2026 aarch64
Page size: 4096 (rules out the known 16K-page aarch64 chromium bugs,
e.g. https://issues.chromium.org/issues/40257452)
Container: pristine debian:trixie (docker.io library image), nothing
installed except chromium + deps via apt
Memory/CPU: 7.9 GB / 12 cores available to the VM (not resource-starved)
Architecture: native arm64 end to end â NO Rosetta/QEMU instruction
translation involved
================================================================================
3. RESULT MATRIX (all in identical pristine debian:trixie containers)
================================================================================
Command under test:
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
| build | source | result |
|-----------------------------------------|-------------------|---------------|
| 147.0.7727.137-1~deb13u1 | trixie (plain) | exit 0, DOM OK|
| 150.0.7871.46-1~deb13u1 | trixie-security | exit 133 |
| 148.0.7778.0 (Playwright chromium-1223) | playwright.dev | exit 0, DOM OK|
Isolation variants tested against 150 â ALL crash identically (exit 133):
- default Docker seccomp profile
- --security-opt seccomp=unconfined
- --privileged
- flag combinations: --disable-dev-shm-usage, --disable-crashpad,
--no-zygote, --single-process (individually and combined)
The seccomp/privileged results argue AGAINST a sandbox-validation or
syscall-filtering mechanism: relaxing all confinement changes nothing.
================================================================================
4. VERBOSE STDERR â TAIL BEFORE DEATH
================================================================================
(chromium --headless=new --no-sandbox --disable-gpu --enable-logging=stderr
--v=1 --dump-dom about:blank ; last lines, PIDs from the recorded run)
[2567:2567:...] WARNING:sandbox/policy/linux/sandbox_linux.cc:405]
InitializeSandbox() called with multiple threads in process gpu-process.
[2526:2553:...] ERROR:dbus/bus.cc:405] Failed to connect to the bus: Could not
parse server address: Unknown address type ...
[2526:2526:...]
VERBOSE1:components/proxy_config/pref_proxy_config_tracker_impl.cc:462] set
chrome proxy config service ...
[2526:2526:...]
VERBOSE1:components/signin/core/browser/account_reconcilor.cc:254]
AccountReconcilor::RegisterWithIdentityManager
[0706/131945.241897:ERROR:third_party/crashpad/crashpad/util/file/file_io_posix.cc:145]
open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or
directory (2)
[0706/131945.241954:ERROR:third_party/crashpad/crashpad/util/file/file_io_posix.cc:145]
open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or
directory (2)
exit: 133
Notes:
- No FATAL log line is emitted before the trap.
- The crashpad cpufreq errors are the crash HANDLER annotating the already-
in-flight crash (linuxkit exposes no cpufreq sysfs); they are a symptom
marker, not the cause.
- The dbus errors are environmental noise: the WORKING 147 and 148 runs
print the same dbus errors and render fine.
- Startup gets far: GPU process, storage service, network service, disk
cache, and profile init all complete before the trap.
================================================================================
5. GDB â FATAL SIGNAL CAPTURE (default multi-process mode)
================================================================================
gdb -q -batch -ex "handle SIGTRAP stop" -ex run -ex bt \
--args /usr/lib/chromium/chromium --headless=new --no-sandbox --disable-gpu
--dump-dom about:blank
Thread 1 "chromium" received signal SIGTRAP, Trace/breakpoint trap.
0x0000aaaac831bb9c in ?? ()
#0 0x0000aaaac831bb9c in ?? ()
#1 0x0000002c007029b8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Notes:
- The trap lands on THREAD 1 OF THE BROWSER PROCESS (not a renderer/child).
- Frame #0 is inside the main chromium text segment (0xaaaa... is the
executable's mapping base on this kernel); the binary is stripped, so no
symbol names without chromium-dbgsym. Happy to re-run with dbgsym from
debian-debug on request for a named backtrace.
- Frame #1's address (0x2c007029b8) sits outside normal library mappings,
consistent with a V8/JIT-region or pointer-compression-cage address â
or simply with IMMEDIATE_CRASH() leaving no unwindable caller frame.
- aarch64 IMMEDIATE_CRASH() compiles to a brk instruction, which raises
exactly this: SIGTRAP with no core-dumping signal and no FATAL log.
================================================================================
6. REPRODUCTION (from any Apple Silicon Mac with Docker Desktop)
================================================================================
# broken build (trixie-security):
docker run --rm debian:trixie bash -c '
apt-get update -qq && apt-get install -y -qq --no-install-recommends chromium
chromium --version
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
echo "exit: $?"'
# -> Chromium 150.0.7871.46 ... exit: 133, no DOM output
# control (plain trixie, same container recipe):
docker run --rm debian:trixie bash -c '
apt-get update -qq && apt-get install -y -qq --no-install-recommends \
chromium=147.0.7727.137-1~deb13u1 chromium-common=147.0.7727.137-1~deb13u1 \
chromium-sandbox=147.0.7727.137-1~deb13u1
chromium --version
chromium --headless=new --no-sandbox --disable-gpu --dump-dom about:blank
echo "exit: $?"'
# -> Chromium 147.0.7727.137 ... <html>...</html> exit: 0
================================================================================
7. WHAT THE EVIDENCE SUPPORTS (and what it rules out)
================================================================================
Supported:
- A regression introduced between 147.0.7727.137 and 150.0.7871.46 as built
for Debian arm64, manifesting as a release-build CHECK / IMMEDIATE_CRASH
in the browser process under the linuxkit 6.12 VM kernel.
Ruled out by direct test:
- Container/image configuration (pristine debian:trixie reproduces it)
- seccomp filtering (unconfined crashes identically)
- Privilege/capability restrictions (--privileged crashes identically)
- 16K page size (this VM uses 4K pages)
- dbus absence, /dev/shm size, crashpad, zygote, process model (all varied,
no effect)
- Instruction translation (native arm64 host and image; no Rosetta/QEMU)
Unknown (needs symbols or upstream knowledge):
- The specific CHECK that fires. A dbgsym-resolved backtrace can be
provided on request.
Workaround in production use: pin the test-bed browser to Playwright's
chromium distribution and treat apt chromium purely as a shared-library
donor. Bare-metal/native-Linux users appear unaffected.
