Exit code 134 indicates your Docker container terminated itself with SIGABRT (signal 6). This typically happens due to failed assertions, explicit abort() calls in code, memory corruption issues like double-free errors, or incompatible library bindings. Debugging requires examining application logs and potentially running with the --init flag.
Exit code 134 in Docker means your container process terminated via SIGABRT (abort signal). The exit code is calculated as 128 + signal number, and since SIGABRT is signal 6, the result is 134. Unlike SIGKILL which comes from external sources, SIGABRT is typically self-inflicted - the process itself triggers the abort. This makes it a more complex error to debug because the root cause is inside your application code or its dependencies. Common scenarios that trigger SIGABRT: 1. **Calling abort()**: An application explicitly calls the C library `abort()` function to terminate immediately when it detects an unrecoverable error. 2. **Failed Assertions**: When debugging assertions (`assert()` macro) fail, they trigger abort. This often indicates a programming bug where a condition that should never be false was violated. 3. **Memory Corruption**: Issues like double-free errors, heap corruption, or buffer overflows can trigger abort from memory allocators like glibc. 4. **Uncaught Exceptions in Native Code**: Some runtimes (Go, Rust, C++) abort when they detect unrecoverable errors like stack overflow or memory safety violations. 5. **Library Incompatibilities**: Mismatched versions of native libraries (especially glibc-related) can cause abort during dynamic linking or execution. The SIGABRT signal cannot be blocked or ignored - once triggered, the process will terminate. This is intentional to ensure corrupted processes don't continue running.
Start by examining what your application logged before the abort:
docker logs <container_name_or_id> --tail 200Look 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 outputGet detailed container state information:
docker inspect --format='{{json .State}}' <container_name_or_id> | jqThis 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.jsonReview 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: trueNote: 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 valgrindThen run with Valgrind:
docker run --rm <image> valgrind --leak-check=full ./your-applicationFor 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/binaryCheck glibc version:
docker run --rm <image> ldd --versionCommon 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/binary2. Static linking for portability:
gcc -static -o app app.c3. 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 compatibilityIf 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 productionUse:
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: 16777216In 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 unlimitedThen analyze with gdb:
docker run -it --rm -v /tmp/cores:/cores <image> \
gdb /path/to/binary /cores/core.12345In gdb:
(gdb) bt # Show backtrace
(gdb) frame 0 # Go to crash frame
(gdb) info locals # Show local variablesExit code calculation: In Unix/Linux, when a process is terminated by a signal, its exit code equals 128 plus the signal number. SIGABRT is signal 6, so 128 + 6 = 134. Related exit codes:
- 134 = SIGABRT (128 + 6, abort)
- 137 = SIGKILL (128 + 9, killed)
- 139 = SIGSEGV (128 + 11, segmentation fault)
- 143 = SIGTERM (128 + 15, terminated)
PID 1 and signal behavior: When running as PID 1 without --init, the Linux kernel applies special rules. Default signal handlers aren't automatically registered, which can cause unexpected behavior. Some programs that call abort() may produce exit code 139 (SIGSEGV) instead of 134 due to this. The --init flag resolves this by running tini as PID 1.
glibc vs musl: If building on glibc-based systems (Debian, Ubuntu) and running on Alpine (musl), you may encounter SIGABRT. Options:
1. Build on Alpine
2. Use alpine:edge with apk add gcompat
3. Static link against musl: CC=musl-gcc
Thread sanitizer for race conditions: Concurrent bugs can cause corruption leading to abort:
TSAN_OPTIONS=second_deadlock_stack=1 ./appDebugging Go panics: Go runtime panics appear as SIGABRT. Use GOTRACEBACK=crash to generate core dumps:
docker run -e GOTRACEBACK=crash <go-app-image>Rust abort behavior: Rust panics abort by default in release builds when panic = 'abort' is set in Cargo.toml. Set RUST_BACKTRACE=1 for better diagnostics.
docker-compose specific issue: Some versions of docker-compose installed via pip have a known issue causing exit code 134 on certain systems. If docker-compose itself is crashing with 134, try installing via the official binary download instead of pip.
unable to configure the Docker daemon with file /etc/docker/daemon.json
How to fix 'unable to configure the Docker daemon with file daemon.json' in Docker
docker: Error response from daemon: OCI runtime create failed: container_linux.go: starting container process caused: exec: "/docker-entrypoint.sh": stat /docker-entrypoint.sh: no such file or directory
How to fix 'exec: entrypoint.sh: no such file or directory' in Docker
image operating system "linux" cannot be used on this platform
How to fix 'image operating system linux cannot be used on this platform' in Docker
dockerfile parse error line 5: unknown instruction: RRUN
How to fix 'unknown instruction' Dockerfile parse error in Docker
manifest unknown: manifest unknown
How to fix 'manifest unknown' in Docker