Linux system errors

Arithmetic Fault

136
MediumLinux System

Reviewed for reference consistency: August 11, 2026

an integer division by zero or similar math trap, despite the name

What 136 Means

The 136 error on the Linux system errors indicates arithmetic fault — an integer division by zero or similar math trap, despite the name. This typically occurs due to integer division by zero in compiled code.

Exit code 136 carries 128 + 8, SIGFPE. In practice the trigger is an integer division by zero; the floating-point name is a historical leftover.

How to fix 136

General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.

  1. Trap the fault in a debugger

    Running under gdb and requesting a backtrace at the moment of the trap points at the exact division.

    gdb -q ./your_program -ex run -ex bt
  2. Keep the program's dying words

    Some runtimes print arithmetic diagnostics before death; the tail of standard error preserves them.

    ./your_program 2>&1 | tail -n 20

Technical Background

Despite the F in its name, the trap is rarely floating point. IEEE 754 gives every float operation a defined answer, including divisions by zero, so compiled numeric code sails through infinities without a peep. The CPU's arithmetic trap fires where the standard has no answer to give: integer division by zero.

That asymmetry surprises developers moving from scripts to compiled code. A shell or Python session shrugs at a zero divisor with a catchable exception, while the same formula in C or Rust (in a debug-unwrapped path) becomes a signal 8 death the moment the denominator lands on zero.

The exotic second case is signed overflow at the extreme: the one integer division whose mathematically correct result does not fit back into the type, which traps on x86 as surely as a zero divisor.

Common Causes

  • Integer division by zero in compiled code
  • Dividing INT_MIN by -1, whose result overflows the integer type
  • A floating-point trap mode explicitly enabled by the program, uncommon by default

Typical Scenarios

  • A C program dividing by a denominator read from configuration that a deployment left empty or zero
  • A numeric kernel in a simulation crashing after an upstream computation produced a zero divisor
  • A fixed-size integer path hitting the INT_MIN / -1 overflow edge during a normalization step

What to Know

A debugger attached to the failing run names the exact instruction and the denominator's origin, turning the trap into a line number. The kernel log confirms the arithmetic nature of the death for the record.

Frequently Asked Questions

Common questions about Linux 136 error

IEEE 754 arithmetic defines division by zero as infinity or NaN, delivered as a normal value. Only integer division lacks a defined result for a zero divisor, so the CPU traps with SIGFPE.

Overwhelmingly, yes, in default-built programs. The remaining cases are integer overflow edges like INT_MIN divided by -1, and explicitly enabled floating-point trap modes that most builds never touch.

136 is the CPU trapping on an impossible arithmetic operation; 134 is the program calling abort() after its own checks failed. A trap comes from the hardware, an abort from the code's judgment.

Related Error Codes

Related Errors From Other Categories

Similar error codes documented across different platforms and systems