Linux system errors
Trace Trap
Reviewed for reference consistency: August 11, 2026
a breakpoint or trap instruction fired, normally under a debugger's control
What 133 Means
The 133 error on the Linux system errors indicates trace trap — a breakpoint or trap instruction fired, normally under a debugger's control. This typically occurs due to a software breakpoint (int3 on x86) executed while no debugger was attached to absorb it.
Exit code 133 combines 128 with signal 5, SIGTRAP — the breakpoint signal debuggers live on, firing when a trap instruction executes with nobody positioned to absorb it.
How to fix 133
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.
Watch the process under a tracer
Running the program under strace with signal reporting shows whether an attached tool or a stray instruction produces the trap.
strace -o trace.log ./your_programInspect the process interactively
A gdb session around the failure point turns an opaque 133 exit into a specific line and stack.
gdb -q ./your_program
Technical Background
Debuggers own signal 5. Every breakpoint a developer sets in gdb is really an int3 instruction swapped into the code stream; when the CPU reaches it, the kernel raises SIGTRAP, the debugger catches it, shows the developer the state, and quietly restores the original byte. The signal is the mechanism, not the malfunction.
Without a debugger in the loop the design collapses to its default: the process dies and the shell records 133. That is why an orphaned breakpoint or a tracing agent removed from the equation leaves behind an exit code that looks exotic — the machinery was always there, minus its operator.
Tracing systems built on ptrace speak SIGTRAP natively, which is why stops under strace-style tools and debugger sessions share this signature.
Common Causes
- A software breakpoint (int3 on x86) executed while no debugger was attached to absorb it
- A ptrace-based tool pausing the process and the stop surfacing as a trap exit
- Single-step trap flag left enabled after a debugging session detached uncleanly
Typical Scenarios
- A process under gdb hitting a breakpoint the developer set before the crash investigation
- A binary instrumented by a tracing or anti-tamper tool that planted int3 instructions of its own
- A debugger detaching uncleanly and leaving the architecture's single-step flag lit
What to Know
The key question is what planted the trap: an active debugging session, instrumentation inside the binary, or a stale flag from a previous session. Tracing the process's syscall stream shows whether a supervisor is attached.
Frequently Asked Questions
Common questions about Linux 133 error
The usual suspects are a leftover breakpoint baked into the binary, a tracing tool that planted trap instructions, or an unclean debugger detach that left the single-step flag set. The signal still fired even though no one was there to catch it.
Rarely. The instruction was deliberate — placed by a debugger or instrumentation. Code that executes an int3 outside a debugging context is usually instrumented code whose controller is missing.
Both are instruction-level faults, but 133's trap instruction was intentional and 132's opcode was not executable at all. A trap means someone planned the stop; an illegal instruction means nobody did.
Related Error Codes
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Illegal Instruction — the CPU reached an opcode it cannot decode or execute
Self-Abort — the process called abort() after detecting a state it cannot recover from
Invalid Exit Argument — script exited with an out-of-range status or terminated by a signal
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
You have unresolved file conflicts preventing Git from completing the current operation.
You tried to add a remote named 'origin', but one with that name already exists.
Git does not know which remote branch should receive your pushed commits.
You checked out a specific commit, detaching your working directory from the branch history.