Python script crashing with Segmentation Fault (core dumped) inside Docker Alpine

A Python process crashing with Segmentation fault (core dumped) inside an Alpine Linux Docker container is primarily caused by C-extension memory allocation incompatibilities between Alpine’s musl libc implementation and glibc-compiled C extensions or binaries. Python packages containing pre-compiled C/C++ wheels (such as numpy, grpcio, pillow, pandas, or cryptography libraries) are typically linked against glibc using manylinux wheel specifications. When executing these extensions under Alpine’s musl C standard library, memory stack size limits differ significantly (musl defaults to an 80KB-128KB stack per thread versus glibc’s 2MB–8MB), and missing glibc compatibility layers cause memory access violations and immediate core dumps.

Root Cause Diagnosis

Python wheels compiled for standard Linux distributions rely on glibc symbols and specific thread stack allocations that Alpine Linux does not provide natively. When C extensions invoke multi-threaded operations, deep recursive C calls, or native memory allocations, musl‘s constrained default thread stack size overflows, causing a SIGSEGV runtime crash. Furthermore, using gcompat or libc6-compat abstraction wrappers under Alpine fails to translate complex memory-mapping calls (mmap/malloc differences), leading to invalid memory reference faults during native C code execution.

Quick Fix

Switch the base Docker image from python:alpine to a glibc-based slim image like python:3.11-slim-bookworm in your Dockerfile:

# Replace alpine base image
# FROM python:3.11-alpine 

# Use Debian-based slim image
FROM python:3.11-slim-bookworm

Step-by-Step Resolution

Step 1: Rebuild Python C-Extensions from Source (If Staying on Alpine)

If Alpine is strictly required by image size constraints, disable pre-compiled wheel installations to force pip to compile C extensions natively against Alpine’s musl libc headers.

FROM python:3.11-alpine

# Install build tools and musl development headers
RUN apk add --no-cache \
    gcc \
    g++ \
    musl-dev \
    linux-headers \
    libffi-dev \
    openssl-dev \
    python3-dev

WORKDIR /app
COPY requirements.txt .

# Force compilation from source against musl libc
RUN pip install --no-cache-dir --no-binary :all: -r requirements.txt

COPY . .
CMD ["python", "main.py"]

Step 2: Increase Thread Stack Size Environment Variables

If the crash occurs during multi-threaded C extension calls (such as OpenBLAS, PyTorch, or NumPy execution) within Alpine, override the process thread stack allocation limit inside the Dockerfile or container runtime.

FROM python:3.11-alpine

# Set stack size to 2MB (2097152 bytes) to prevent musl thread stack overflow
ENV PYTHONFAULTHANDLER=1
ENV LD_PRELOAD=/lib/libgcompat.so.0

RUN apk add --no-cache gcompat

# Environment variable for extensions using C-threads
ENV PTHREAD_STACK_MIN=2097152

COPY . /app
WORKDIR /app
CMD ["python", "main.py"]

Step 3: Enable Python Fault Handler for Diagnostic Backtraces

To pinpoint the exact C library or extension module causing the memory fault, enable Python’s native fault handler in your entry point command to print C-level stack traces upon SIGSEGV.

# Update entrypoint to trace C-level segmentation faults
CMD ["python", "-X", "faulthandler", "main.py"]

Why This Fails for Some Users

OpenBLAS / Scipy Multi-Threading Deadlocks: Packages like numpy or scipy dynamically link to OpenBLAS. OpenBLAS spawns worker threads assuming glibc stack sizes; when executed on musl, worker threads exceed the musl thread stack limit instantly, dumping core even if compiled from source.
Rust and C++ ABI Name Mangling: Rust-based Python extensions (e.g., cryptography, pydantic-core) require musllinux wheel variants (musllinux_1_1_x86_64). Forcing installation of manylinux wheels using overridden pip flags (--extra-index-url) injects glibc ABI binaries directly into a musl environment, guaranteeing segmentation faults.
Kernel Security Modules (AppArmor / SELinux): Linux host environments with aggressive memory protection profiles block memory page re-mapping (mprotect calls with PROT_EXEC) performed by specific JIT-compiling Python C modules running inside unprivileged Alpine containers.
PyInstaller Single-Binary Executables: Running PyInstaller binaries built on a glibc host inside an Alpine container causes immediate loader aborts or segmentation faults during initial binary extraction to /tmp.