mongo 8.0.5+ crash-loops with SIGSEGV (exit 139) on arm64 / Raspberry Pi 5; 8.0.4 is fine

Summary

On arm64 (Raspberry Pi 5, Cortex-A76 / ARMv8.2-A), mongod from the official image starts, runs for a short time, then dies with SIGSEGV (docker events shows die exitCode=139) and loops forever under a restart policy. No graceful shutdown and no fatal log line is emitted; the next start just reports "Detected unclean shutdown."

Bisecting the published tags gives a clean boundary: 8.0.4 is the last good release; 8.0.5 is the first that crash-loops, and every release after it (8.0.6 → 8.0.26, all 8.2.x, all 8.3.x, latest) is affected.

Reproduction

docker run --rm mongo:8.0.5     # SIGSEGV (exit 139), crash-loops roughly every ~30s
docker run --rm mongo:8.0.4     # runs fine

No app, config, replica set, or volumes required — a bare docker run reproduces it. To watch the crash:

docker events --filter image=mongo:8.0.5 --filter event=die \
  --format '{{.Time}} exit={{.Actor.Attributes.exitCode}}'

Bisect (one standalone container per version)

There is no published 8.0.2 or 8.0.7, so 8.0.4 → 8.0.5 is the exact consecutive boundary in the official images.

Environment

• Image: official library/mongo, tags 8.0.5+ (build: allocator: tcmalloc-google, distmod: ubuntu2404, distarch: aarch64)
• Host: Raspberry Pi 5, Cortex-A76 (ARMv8.2-A), Ubuntu kernel 7.0.0-1010-raspi, page size 4096
• Docker 29.5.1

Details

• Exit is 139 = SIGSEGV; no backtrace and no shutdown sequence is logged before death.
• GLIBC_TUNABLES=glibc.pthread.rseq=0 (from #723) is present in the container env and does not prevent it.
• Not OOM (State.OOMKilled=false, memory.events: oom_kill 0). Not the older Pi 4 "Illegal instruction"/SIGILL case (#510, #508, #485) — this CPU is ARMv8.2-A and the signal is SIGSEGV, and 8.0.4 on the same host is stable.

Start by reproducing the failure with docker run --rm mongo:8.0.5 and compare it with mongo:8.0.4; use docker events and the reported container state to confirm the SIGSEGV. The payload names no source files or tests, so completion would require identifying the regression and verifying that the affected arm64 images no longer crash-loop.