SIGSEGV on x86_64 macOS after commit 843bb729 (observer/lobby Phase 1 scaffold) — Discord gateway crash loop #1531

Summary

After building openab from commit 843bb729 (PR #1470 — feat(cp): observer/lobby — 3-phase design + Phase 1 protocol scaffold), the binary crashes with SIGSEGV within ~1 second of startup, during Discord gateway initialization. The crash is 100% reproducible on x86_64 macOS and affects all bot instances using the binary.

Reverting to the previous commit (6b75b559 — release: v0.10.0-beta.4) resolves the issue — the binary starts and connects to Discord normally.

Environment

• OS: macOS 12.7.6 (Darwin 21.6.0), x86_64 (MacBookAir8,1)
• openab version: 0.10.0 (built from openab-0.10.0-beta.4-1-g843bb729)
• Rust toolchain: whatever rust:1-bookworm digest resolves to (local build on macOS)
• serenity: 0.12.5
• miniz_oxide: 0.8.9
• Discord adapter: serenity EventHandler, single-shard

Crash details

exception: EXC_BAD_ACCESS (SIGSEGV)
subtype: KERN_INVALID_ADDRESS at 0xffffffff8d8b4cd8
termination: Segmentation fault: 11
faultingThread: tokio-rt-worker
procLaunch: 2026-09-11 02:30:40 +0800
captureTime: 2026-09-11 02:30:43 +0800  (uptime ~3s)

Faulting thread stack trace

[0] miniz_oxide::inflate::core::decompress::ha4af5becec82c83a
[1] (imageIndex=4, offset=4096 — likely miniz_oxide C FFI)
[2] serenity::gateway::bridge::shard_runner::ShardRunner::run::{{closure}}::{{closure}}::heeab64bd49e11880
[3] <core::pin::Pin<P> as core::future::future::Future>::poll::h47405e88f73f0460
[4] serenity::gateway::bridge::shard_queuer::ShardQueuer::start::{{closure}}::{{closure}}::{{closure}}::h48d65a69c50a98e3
[5] tokio::runtime::task::core::Core<T,S>::poll::h57cb52406fb330d7
[6] tokio::runtime::task::harness::Harness<T,S>::poll::hd4e9f6aeb80f2bd8
[7] tokio::runtime::scheduler::multi_thread::worker::Context::run_task::ha2434e918548efcc
[8] tokio::runtime::scheduler::multi_thread::worker::Context::run::hdc386423854924a0
[9] tokio::runtime::context::scoped::Scoped<T>::set::h4ec05c94c9b414f4
[10] tokio::runtime::context::runtime::enter_runtime::h1953d280a4f9ee99
[11] tokio::runtime::scheduler::multi_thread::worker::run::h43533dc389e46b04
[12] <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll::hb944237bd2223b7f
[13] tokio::runtime::task::core::Core<T,S>::poll::h9eecbb5319a380c8
[14] tokio::runtime::task::harness::Harness<T,S>::poll::h6709a8c8aff5ac20

The crash occurs inside miniz_oxide::inflate::core::decompress, called from serenity's ShardRunner — i.e., during Discord gateway WebSocket decompression. The address 0xffffffff8d8b4cd8 is clearly an invalid pointer (high 32 bits all set), suggesting a null or uninitialized pointer dereference in the inflate path.

Log output before crash

INFO openab: config loaded agent_cmd=... pool_max=10 discord=true
INFO openab: starting discord adapter allow_all_channels=true ...
INFO openab: control socket listening path=/tmp/openab_glm.sock
INFO openab: discord bot running
<crash — never reaches "discord bot connected">

Reproduction

1. Build from commit 843bb729 on x86_64 macOS
2. Run openab run -c <config_with_discord_adapter.toml>
3. Binary crashes with SIGSEGV within ~1 second

Workaround

Revert to 6b75b559 (beta.4 release commit) — crash does not occur.

Impact

This caused a production incident: 6 Discord bot instances entered a crash-loop (launchd KeepAlive restarted the process every ~10s), resulting in ~1700+ Discord gateway connection attempts within ~4 hours. Discord automatically reset all 6 bot tokens due to the abnormal connection pattern.

Notes

• The crash is in miniz_oxide (zlib decompression) called from serenity's WebSocket shard runner — this is the Discord gateway inflate path
• PR feat(cp): observer/lobby — 3-phase design + Phase 1 protocol scaffold (PR 2/4) #1470 touches the CP (control plane) observer/lobby scaffold, which should be orthogonal to the Discord adapter — the crash path suggests an indirect regression (possibly a dependency version bump or a shared code path)
• The previous known x86_64 macOS crash was SIGILL (Illegal instruction) in 0.10.0-beta.1~beta.3, which was added to a local bad-version blocklist — this is a different crash type (SIGSEGV) at a different location

Full crash report

Attached below as a file.