How to fix Container exited with code 139 (SIGSEGV - Segmentation fault) in Docker

DockerADVANCEDHIGHUpdated Dec 1, 2025· 319 views

Exit code 139 occurs when a Docker container receives SIGSEGV (signal 11), indicating a segmentation fault caused by invalid memory access. This typically results from application bugs, library incompatibilities, or hardware issues requiring debugging and code analysis to resolve.

Quick fix

Fixes 139

# View recent kernel messages
dmesg | tail -n 50 | grep -i segfault

# Or with journalctl
journalctl -k --since "10 minutes ago" | grep -i segfault

# Example output:
# [12345.678] app[1234]: segfault at 0 ip 00007f... sp 00007ff... error 4 in libc.so.6
  1. Check kernel logs for segfault details
  2. Examine container logs for context
  3. Test application outside Docker
  4. Check for library compatibility issues
docker — error
# View recent kernel messages
dmesg | tail -n 50 | grep -i segfault
# Or with journalctl
journalctl -k --since "10 minutes ago" | grep -i segfault
# Example output:
# [12345.678] app[1234]: segfault at 0 ip 00007f... sp 00007ff... error 4 in libc.so.6
Container exited with code 139 (SIGSEGV - Segmentation fault)

What this error means

Exit code 139 is calculated as 128 + 11 (signal number), indicating that the container's main process was terminated by SIGSEGV (Signal 11 - Segmentation Violation). A segmentation fault occurs when a program attempts to access memory that it is not allowed to access, such as reading from or writing to an invalid memory location, dereferencing null pointers, or accessing memory that has been freed. Unlike application-level errors (exit code 1) or out-of-memory kills (exit code 137), exit code 139 represents a low-level memory access violation detected by the kernel. The operating system terminates the process immediately to prevent memory corruption or security vulnerabilities. This error often points to bugs in native code, incompatible libraries, or in rare cases, hardware issues like faulty RAM.

Typical symptoms

  • Container terminates abruptly with 'Exited (139)' status
  • Kernel logs show 'segfault' messages for the container process
  • Application crashes randomly without clear error messages
  • Container works on some hosts but fails on others
  • Errors occur consistently at specific operations or inputs
  • dmesg output shows 'segfault at' entries with memory addresses
  • Core dump files are generated (if enabled)
  • Container exits immediately or after running for some time

Common causes

  1. Application code bug causing null pointer dereference or buffer overflow
  2. Incompatible library versions linked against the application binary
  3. Binary compiled for different CPU architecture (e.g., x86_64 vs ARM64)
  4. Corrupted application binary or shared libraries in the container image
  5. Incompatibility between Alpine-based images and certain native extensions (musl vs glibc)
  6. Memory corruption from race conditions in multi-threaded applications
  7. WSL2 or platform-specific incompatibilities with older base images
  8. Faulty host RAM or hardware issues causing memory corruption
  9. Incompatible CPU instruction sets (AVX/SSE) between build and runtime environments
  10. Stack overflow from deeply recursive code or large stack allocations

How to fix "Container exited with code 139 (SIGSEGV - Segmentation fault)"

1Check kernel logs for segfault details

First, inspect the host's kernel logs to find details about the segmentation fault:

bash
# View recent kernel messages
dmesg | tail -n 50 | grep -i segfault

# Or with journalctl
journalctl -k --since "10 minutes ago" | grep -i segfault

# Example output:
# [12345.678] app[1234]: segfault at 0 ip 00007f... sp 00007ff... error 4 in libc.so.6

The output shows the memory address, instruction pointer, and which library caused the fault. Error codes: 4 = user-mode read, 5 = user-mode write, 6 = user-mode execute.

2Examine container logs for context

Check what the application was doing before the crash:

bash
# Get container ID
docker ps -a

# View logs (may be empty if crash was immediate)
docker logs <container-id>

# Inspect container state
docker inspect --format '{{.State.ExitCode}} {{.State.Error}} {{.State.FinishedAt}}' <container-id>

Look for patterns: Does it crash during startup, under load, or when processing specific data?

3Test application outside Docker

Determine if the issue is container-specific by running the application directly on the host:

bash
# Build and run natively
./your-application

# Or run in the container interactively
docker run --rm -it <image> /bin/bash
./your-application

If it works outside Docker but crashes inside, the issue is likely:
- Missing shared libraries
- Different glibc/musl versions
- Platform architecture mismatch

4Check for library compatibility issues

Segmentation faults often occur due to library mismatches. Verify library versions:

bash
# Inside the container
ldd /path/to/your/binary

# Check for missing libraries
ldd /path/to/your/binary | grep 'not found'

# List library versions
ls -la /lib/ /usr/lib/

For Alpine-based images, native extensions compiled against glibc may fail. Solutions:

dockerfile
# Switch from Alpine to Debian-based image
FROM python:3.11-slim  # Instead of python:3.11-alpine

# Or install glibc compatibility layer in Alpine
RUN apk add --no-cache libc6-compat
5Verify CPU architecture compatibility

Ensure the binary matches the runtime architecture:

bash
# Check binary architecture
file /path/to/your/binary

# Check container platform
uname -m

# Build for specific platform
docker build --platform linux/amd64 -t myimage .

# Run with explicit platform
docker run --platform linux/amd64 myimage

On Apple Silicon (M1/M2) Macs, x86_64 images run under Rosetta emulation which can cause segfaults with some applications.

6Enable core dumps for debugging

Generate core dumps to analyze the crash with a debugger:

bash
# On the host, enable core dumps
ulimit -c unlimited
echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

# Run container with elevated privileges for debugging
docker run --rm -it \
  --ulimit core=-1 \
  --cap-add=SYS_PTRACE \
  -v /tmp:/tmp \
  <image> /bin/bash

# Inside container, run the application
./your-application

# After crash, analyze with gdb
gdb /path/to/binary /tmp/core.<name>.<pid>
(gdb) bt  # Print backtrace
7Debug with GDB or AddressSanitizer

For compiled applications, use debugging tools to identify the exact crash location:

bash
# Install gdb in container
apt-get update && apt-get install -y gdb

# Run application under gdb
gdb --args ./your-application
(gdb) run
# When it crashes:
(gdb) bt full  # Full backtrace with variables

For C/C++ applications, rebuild with AddressSanitizer:

bash
# Compile with ASan
gcc -fsanitize=address -g -o myapp myapp.c

# Run - ASan will print detailed memory error info
./myapp

For Python applications with native extensions, install debug symbols and use faulthandler:

python
import faulthandler
faulthandler.enable()
8Update or rebuild dependencies

If the crash is in a library, update to compatible versions:

dockerfile
# Update all packages
RUN apt-get update && apt-get upgrade -y

# For Python - reinstall with no cache
RUN pip install --no-cache-dir --force-reinstall <package>

# For Node.js - rebuild native modules
RUN npm rebuild

If using pre-built binaries, try building from source to match your environment:

bash
# Example: rebuild numpy from source
pip install --no-binary :all: numpy
9Check for WSL2 or platform-specific issues

Older base images may have compatibility issues with WSL2 or newer kernels:

bash
# Check if running under WSL2
cat /proc/version | grep -i microsoft

# Update to newer base image
FROM centos:7  # Instead of centos:6
FROM ubuntu:22.04  # Instead of older Ubuntu versions

For WSL2, try creating %userprofile%\.wslconfig and restart:

ini
[wsl2]
kernelCommandLine = vsyscall=emulate

Then: wsl --shutdown and restart Docker Desktop.

10Test with security options disabled

Rarely, seccomp or AppArmor profiles can cause issues (though usually EPERM, not SIGSEGV):

bash
# Test without seccomp filtering
docker run --security-opt seccomp=unconfined <image>

# Test without AppArmor
docker run --security-opt apparmor=unconfined <image>

Warning: Only use these flags for debugging. If this resolves the issue, create a proper custom seccomp profile rather than disabling security entirely.

Advanced notes

Exit code 139 can be particularly challenging to debug because the crash occurs at the kernel level, often leaving minimal application-level logs. In containerized environments, the isolation can make it harder to access debugging tools and core dumps.

Memory alignment issues: Some CPU architectures require aligned memory access. Code that works on x86_64 may crash on ARM64 if it performs unaligned memory operations.

Alpine and musl libc: Alpine Linux uses musl libc instead of glibc. Binaries compiled against glibc may crash with segfaults when run on Alpine. This is especially common with Python packages containing C extensions, Go binaries using cgo, or pre-compiled Node.js native modules. Either use a glibc-based image (Debian, Ubuntu) or rebuild native dependencies on Alpine.

QEMU emulation: When running containers for a different architecture (e.g., ARM containers on x86 via QEMU), some applications may experience segfaults due to emulation limitations or timing-sensitive code.

Hardware verification: In persistent cases, especially in production, run memory tests (memtest86+) to rule out faulty RAM. Memory corruption from hardware issues can cause seemingly random segfaults that are difficult to reproduce or debug.

Kubernetes considerations: In Kubernetes, exit code 139 will cause pod restarts with CrashLoopBackOff. Use kubectl describe pod to view events and kubectl logs --previous to see logs from crashed containers. Consider using sidecar containers with debugging tools or ephemeral containers (kubectl debug) for live debugging.

Frequently asked questions

What does "139" mean?
Exit code 139 is calculated as 128 + 11 (signal number), indicating that the container's main process was terminated by SIGSEGV (Signal 11 - Segmentation Violation). A segmentation fault occurs when a program attempts to access memory that it is not allowed to access, such as reading from or writing to an invalid memory location, dereferencing null pointers, or accessing memory that has been freed. Unlike application-level errors (exit code 1) or out-of-memory kills (exit code 137), exit code 139 represents a low-level memory access violation detected by the kernel.
How do I fix "139"?
Exit code 139 occurs when a Docker container receives SIGSEGV (signal 11), indicating a segmentation fault caused by invalid memory access. This typically results from application bugs, library incompatibilities, or hardware issues requiring debugging and code analysis to resolve.
What causes "139"?
Application code bug causing null pointer dereference or buffer overflow Incompatible library versions linked against the application binary Binary compiled for different CPU architecture (e.g., x86_64 vs ARM64)
Is the "139" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading