How to fix Exited (134) - Container terminated with SIGABRT in Docker

Start by examining what your application logged before the abort:

docker logs <container_name_or_id> --tail 200

Look for patterns indicating the abort cause:
- Assertion failures: "assertion failed", "ASSERT", "precondition failed"
- Memory errors: "double free or corruption", "malloc", "free(): invalid pointer"
- Panic messages: "panic:", "fatal error:", "FATAL"
- Stack traces: Function names leading to abort()

If logs are empty or truncated, try running interactively:

docker run -it --rm <image> /bin/sh
# Then run your application manually to see full output

Get detailed container state information:

docker inspect --format='{{json .State}}' <container_name_or_id> | jq

This shows:
- ExitCode: Should be 134
- OOMKilled: Should be false (134 isn't memory limit related)
- Error: May contain additional context

Also check the full container configuration:

docker inspect <container_name_or_id> > container-info.json

Review environment variables, mounts, and resource limits that might affect behavior.

A common cause of unexpected exit codes in containers is PID 1 signal handling. When your application runs as PID 1, the kernel treats signals differently:

docker run --init <image>

The --init flag adds a tiny init process (tini) as PID 1, which:
- Properly forwards signals to your application
- Reaps zombie processes
- Provides correct default signal handlers

For Docker Compose (v2.4+):

services:
  myapp:
    image: myimage:latest
    init: true

Note: Without --init, some applications may receive unexpected signal numbers or have default handlers that don't work as expected at PID 1.

If memory corruption is suspected, rebuild your application with debugging tools:

Using AddressSanitizer (ASan):

# For C/C++ with GCC/Clang
ENV CFLAGS="-fsanitize=address -g"
ENV CXXFLAGS="-fsanitize=address -g"
ENV LDFLAGS="-fsanitize=address"

Using Valgrind (add to your image):

RUN apt-get update && apt-get install -y valgrind

Then run with Valgrind:

docker run --rm <image> valgrind --leak-check=full ./your-application

For Go applications, enable race detection:

go build -race -o app .

These tools will pinpoint the exact line causing memory corruption.

SIGABRT often occurs when native libraries are incompatible:

Check linked libraries:

docker run --rm <image> ldd /path/to/your/binary

Check glibc version:

docker run --rm <image> ldd --version

Common fixes:

1. Use multi-stage builds to compile on the same base:

FROM debian:bullseye AS builder
RUN apt-get update && apt-get install -y build-essential
COPY . .
RUN make

FROM debian:bullseye
COPY --from=builder /app/binary /app/binary

2. Static linking for portability:

gcc -static -o app app.c

3. Use Alpine-compatible builds if using Alpine base:

# Alpine uses musl instead of glibc
FROM alpine:3.18
RUN apk add --no-cache libc6-compat  # For glibc compatibility

If assertion failures cause the abort, consider your build configuration:

C/C++ - Disable assertions in release builds:

ENV CFLAGS="-DNDEBUG -O2"

The -DNDEBUG flag disables assert() macros.

Better approach - Convert to error handling:
Instead of:

assert(ptr != NULL);  // Aborts in production

Use:

if (ptr == NULL) {
    log_error("Unexpected null pointer");
    return ERROR_NULL_POINTER;
}

For Python/Java - These rarely use SIGABRT directly, but native extensions might. Check C extensions in Python packages or JNI code in Java applications.

Important: Simply disabling assertions hides bugs. Fix the underlying issue when possible.

Stack overflow can trigger SIGABRT in some configurations:

# Check current limits
docker run --rm <image> ulimit -s

# Run with increased stack size
docker run --ulimit stack=16777216:16777216 <image>

For Docker Compose:

services:
  myapp:
    image: myimage:latest
    ulimits:
      stack:
        soft: 16777216
        hard: 16777216

In your application, reduce stack usage:
- Convert deep recursion to iteration
- Move large arrays from stack to heap
- Reduce local variable sizes in recursive functions

For complex crashes, enable core dumps:

# Enable core dumps
docker run --ulimit core=-1 --security-opt seccomp=unconfined \
  -v /tmp/cores:/cores -e CORE_PATTERN=/cores/core.%p <image>

Inside the container, set core pattern:

echo '/cores/core.%p' > /proc/sys/kernel/core_pattern
ulimit -c unlimited

Then analyze with gdb:

docker run -it --rm -v /tmp/cores:/cores <image> \
  gdb /path/to/binary /cores/core.12345

In gdb:

(gdb) bt        # Show backtrace
(gdb) frame 0   # Go to crash frame
(gdb) info locals  # Show local variables