Linux system errors
Bus Error
Reviewed for reference consistency: August 11, 2026
a memory access rejected at the hardware level, often around mmap'd files
What 135 Means
The 135 error on the Linux system errors indicates bus error — a memory access rejected at the hardware level, often around mmap'd files. This typically occurs due to accessing bytes of a memory-mapped file after the underlying file was truncated.
Exit code 135 = 128 + 7, SIGBUS. The memory access died on the hardware path — most often a mapped file whose bytes vanished underneath the mapping.
How to fix 135
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.
Check the kernel log for the fault
The kernel records SIGBUS deliveries with the faulting address, confirming the hardware-level nature of the stop.
dmesg -T | tail -n 30Inspect the mapped file's current size
If the file shrank below what the process mapped, truncated pages explain the bus error directly.
ls -l /path/to/mapped_fileCheck space on the backing filesystem
A full filesystem can leave mapped pages unbacked; the free-space view closes that branch of the diagnosis.
df -h /path/to/mapped_file
Technical Background
SIGBUS sits one level below SIGSEGV. A segfault says the address was never yours; a bus error says the address was yours but the memory system could not deliver it. The address translation succeeded and the physical access failed — which is why the same crash log shows a valid-looking pointer next to a hardware-sounding fault name.
The signature case on Linux is the truncated mmap. A tool maps a 2 GB data file, a rotation script cuts it to zero bytes, and the next page touch crosses into territory with no storage behind it. The kernel has nothing to fill the page from, so signal 7 it is.
Strict-alignment architectures add a second, older meaning: an x86 quietly tolerates misaligned loads that a SPARC or older ARM turns into a bus error. Portable code written casually on x86 discovers this when recompiled elsewhere.
Common Causes
- Accessing bytes of a memory-mapped file after the underlying file was truncated
- Unaligned memory access on architectures that enforce alignment strictly
- Genuine hardware faults on the memory bus, rare on modern systems
Typical Scenarios
- A log rotate or editor truncating a file while a tool keeps mmap pages of it mapped
- A database or indexer crashing with SIGBUS after a cleanup script shrank its data file mid-scan
- A memory-mapped sparse file on a filesystem that ran out of space, leaving mapped pages unbacked
What to Know
The decisive evidence is the lifecycle of the file behind the mapping: its size history and the free space on its filesystem. Kernel logs record the fault, and comparing the mapped file's size against what readers expect exposes a concurrent truncation.
Frequently Asked Questions
Common questions about Linux 135 error
SIGSEGV (exit 139) means the mapping itself is invalid — the process touched memory it never had. SIGBUS (exit 135) means the mapping exists but the hardware could not complete the access, classically because the file backing the mapping lost those bytes.
Yes. A mmap'd sparse or growing file whose blocks cannot be allocated leaves pages with no storage behind them, and the first touch of those pages raises SIGBUS. Checking free space on the file's filesystem is part of the diagnosis.
Accessing a mapped page beyond the file's new end-of-file has no backing storage, so the bus error fires. The safe pattern is to never shrink a file while readers hold it mapped.
Related Error Codes
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Exit Code 139 — process terminated by segmentation fault (Signal 11 / SIGSEGV)
No Space Left — the filesystem ran out of data blocks or of inodes
Resource Busy — the target exists, but another holder refuses to release it right now
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git's internal object database is missing or corrupted.
The operating system denied Git's request for more RAM during a heavy operation.
Git detected corruption inside one of its compressed data bundles (packfiles).
An uncompressed file in Git's internal database has an invalid checksum or zero bytes.