EC
134
BashCRITICALSignalHIGH confidence

Abort (SIGABRT)

Production Risk

CRITICAL — always indicates a real bug (assertion, heap corruption, or explicit abort). Investigate immediately.

What this means

Exit code 134 (128+6) indicates the process called abort() or was sent SIGABRT. This is commonly triggered by assertion failures, heap corruption, or explicitly via abort() in C/C++ programs.

Why it happens
  1. 1An assert() macro failed in a C/C++ program
  2. 2The C runtime detected heap corruption (double-free, buffer overflow)
  3. 3An explicit call to abort() in application code
  4. 4Sanitizer (AddressSanitizer, UBSan) detected undefined behavior
How to reproduce

C program with a failed assertion.

trigger — this will error
trigger — this will error
#!/bin/bash
cat > assert_test.c << 'EOF'
#include <assert.h>
int main() { assert(1 == 0); return 0; }
EOF
gcc -o assert_test assert_test.c
./assert_test
echo "Exit: $?"

expected output

assert_test: assert_test.c:2: main: Assertion '1 == 0' failed.
Aborted (core dumped)
Exit: 134

Fix

Examine the core dump or enable AddressSanitizer

WHEN Debugging a SIGABRT / exit 134

Examine the core dump or enable AddressSanitizer
# Recompile with AddressSanitizer to find heap corruption
gcc -fsanitize=address -g -o myprogram myprogram.c
./myprogram

# Or examine core dump
ulimit -c unlimited && ./myprogram
gdb myprogram core

Why this works

AddressSanitizer catches heap corruption (use-after-free, buffer overflow) that triggers SIGABRT; core dumps show the stack trace at abort().

What not to do

✕ Disable assertions in production to silence this

Assertions catching real bugs; disabling them lets corruption silently proceed, potentially causing worse failures or security vulnerabilities.

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All Bash errors