Exit Code 139 (SIGSEGV) in Docker & Kubernetes
Exit code 139 equals 128 + 11: SIGSEGV, a memory-safety fault the kernel could not resolve. Typical triggers are an invalid read or write, a stack overflow or corrupted control flow in native code. It is not an OOM kill; the process may leave a core file depending on ulimits and core_pattern.
Proof commands: confirm the exit status and the killer
Run these before changing anything. The first two identify what the runtime recorded; the third finds a kernel-level kill on the host. Replace the placeholder container ID, pod name or host path with your own.
Docker inspect
docker inspect <container_id> --format '{{.State.Status}} | ExitCode: {{.State.ExitCode}} | OOMKilled: {{.State.OOMKilled}}'Kubernetes state
kubectl get pod <pod_name> -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.lastState.terminated.reason}{"\tExit:"}{.lastState.terminated.exitCode}{"\n"}{end}'Kernel fault log
sudo dmesg -T | grep -E -i 'segfault|general protection|traps'A segfault log entry usually includes the process name, the fault address and a trap code. If dmesg is quiet, the container may not have permission to write core dumps or the message went to the host's journal. In Kubernetes, search node logs for the pod UID rather than assuming the application log will contain a stack trace.
Three production root causes
128 + 11: a segmentation fault in native code such as C or C++ extensions, Rust unsafe blocks, cgo, JVM or V8 addons, or a glibc/musl mismatch. Pure Go panics exit 2; a Go process that exits 139 crashed in cgo or the runtime.
1. A native memory-safety bug
Use-after-free, null dereference, buffer overflow, unaligned access or a data race in C, C++, Rust unsafe code or a native extension. The application log may end abruptly or contain a partial stack. Reproduce under ASan or with coredump analysis; a Python or Java stack trace alone does not explain a SIGSEGV in a native library.
2. An ABI or libc mismatch
A native module built against glibc loaded into a musl Alpine image, or a C++ library built with a different libstdc++ version, can crash on startup or on first use. This often appears only in the container, not on the developer machine. Pin the base image and build native dependencies in the same image that runs them.
3. A stack overflow or VM/JIT crash
Deep recursion, a small thread stack, or a JIT bug can produce SIGSEGV instead of a clean exception. The JVM writes hs_err_pid*.log, and Go writes a traceback on a panic by default; GOTRACEBACK=crash adds a core dump. Raise the stack limit only after you understand the recursion; a larger stack can hide the defect rather than fix it.
Copy-ready fixes for Docker Compose and Kubernetes
The two manifests set explicit memory limits and a termination grace period. Use them as a baseline, then adjust the values to the measured working set of the service.
docker-compose.yml
A crash is not fixed by memory limits, but a limit still protects the host. Enable core dumps deliberately when debugging: set ulimits.core, a writable core_pattern and enough disk. Do not leave unrestricted core dumps enabled in production.
services:
app:
image: ghcr.io/acme/app:1.4.2
restart: on-failure:3
stop_grace_period: 20s
deploy:
resources:
limits:
memory: 1G
reservations:
memory: 512M
deployment.yaml
Core dumps in Kubernetes depend on the node's core_pattern and on a writable volume; a container crash does not automatically produce a file you can read with kubectl. Capture the node's dmesg and the application's own crash log first, then reproduce with the same image and architecture.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
replicas: 2
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
terminationGracePeriodSeconds: 30
containers:
- name: app
image: ghcr.io/acme/app:1.4.2
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "2000m"
memory: "1Gi"
env:
- name: GOTRACEBACK
value: "crash"
Capture a usable core or crash report
A stack trace without symbols is usually not enough to locate the fault.
# Host: allow core dumps for the crashing process
ulimit -c unlimited
sysctl -w kernel.core_pattern=/var/crash/core.%e.%p
# systemd-coredump: list and inspect the latest crash
coredumpctl list
coredumpctl info <pid>
# Go with cgo: force a crash traceback
GOTRACEBACK=crash ./appFrequently asked questions
Is exit code 139 an OOM kill?
No. OOM kills are SIGKILL and appear as 137, often with OOMKilled true. Exit 139 is SIGSEGV, a fault raised by the CPU and delivered by the kernel because the process accessed memory incorrectly. A memory limit can make an allocation fail, but that normally surfaces as an application error, not a segfault.
How do I get a core dump from a Docker container?
Set a core ulimit, a writable core_pattern and a volume for the output, then let the process crash. On many hosts systemd-coredump captures the core instead; use coredumpctl on the host. For Kubernetes, the node's core_pattern decides where the file goes, so configure the node or run a debug pod with the same image.
Why does my Go program exit 139 instead of a panic?
Pure Go code raises a panic and normally exits 2. A 139 means the fault happened in native code reached through cgo, a native library, or the Go runtime itself. Set GOTRACEBACK=crash, check the native dependency's libc and architecture, and reproduce with the same image.
Related exit codes, signals and network references
Follow the status you actually observed, then check the related port or calculator when the failure involves networking, exposure or firewall rules.
Reference basis: POSIX signal semantics (128 + n), Docker container exit status conventions, and Kubernetes container termination behaviour. Verify the exact behaviour against your runtime version before relying on it in an incident.
Last reviewed 2026-11-06 · All exit codes · Developer tools · Privacy