Exit code 134: The process was terminated by SIGABRT — it aborted itself

134 is 128 + 6, meaning SIGABRT. The process deliberately aborted, usually because a runtime assertion failed, an uncaught exception reached the top, or the allocator detected heap corruption.

Applies to: All Kubernetes versions, Linux nodes

What it means

Signal 6 is SIGABRT, raised by a process against itself via abort(). This is not something the kernel or Kubernetes does to a container — the program decided its own state was unrecoverable. C and C++ programs abort on failed assertions, uncaught exceptions, and detected heap corruption such as a double free. The JVM aborts on fatal internal errors and writes an hs_err_pid file. Go runtimes exit differently, but cgo-linked code can abort. The practical significance is that a 134 is an application bug rather than an environment problem, with one important exception: memory pressure can push an allocator into an abort path, so a container that is close to its limit can produce 134 rather than the 137 you would expect.

Most common causes

• A failed assertion in C or C++ code.
• An uncaught C++ exception propagating out of main, or a std::terminate call.
• Heap corruption detected by glibc — a double free, or writing past the end of an allocation.
• A JVM fatal error, which writes a crash log naming the failing thread and frame.
• A native library called through a language binding aborting internally.
• Allocation failure under memory pressure, where the program aborts rather than being OOM-killed.

How to diagnose it

1. Read the previous logs: kubectl logs POD --previous. An abort almost always prints an assertion message or a stack trace first.
2. Confirm the termination reason is not OOMKilled: kubectl describe pod POD. If it is, treat it as a memory problem instead.
3. For the JVM, retrieve the hs_err_pid file. Write it to a mounted volume so it survives the container's death.
4. Check whether memory usage was near the limit at the time — an abort that only happens under load points at allocation failure rather than a logic bug.
5. Enable core dumps to a persistent volume if the crash is reproducible and the stack trace is not enough.

How to fix it

1. Fix the underlying application defect. This code reports a bug, not a misconfiguration.
2. If the abort happens only under memory pressure, raise the limit and see whether it disappears — that distinguishes an allocation failure from a logic error.
3. Configure crash artefacts to be written to a volume that outlives the container, or the evidence is destroyed on every restart.
4. Pin native library versions so a transitive upgrade cannot introduce an abort path silently.

Notes

Because the process aborts itself, the exit is immediate and any buffered output may be lost. Unbuffered logging is worth enabling on a workload that produces 134, or the most important lines will be the ones you never see.

Related

• Exit code 139 — Terminated by SIGSEGV
• OOMKilled — Killed by the kernel for exceeding the memory limit

Sources

• Linux manual page — signal(7)
• Kubernetes documentation — Debug Running Pods
• Kubernetes documentation — Pod Lifecycle: container states