docs: log Chrome SIGBUS incident from Btrfs csum corruption
Chrome crashed repeatedly with SIGBUS on launch. Root cause was a corrupt data block in ~/.config/google-chrome/Profile 2/Favicons on a single-copy Btrfs volume (csum failures correlated to the second with each crash). A scrub found two further uncorrectable blocks (a Chrome cache file and a gdm help file); both fixed. SSD SMART is clean and the corruption is static across scrubs, pointing at a past RAM/bus event rather than a failing drive. Adds docs/incidents.md (dated incident log) and a CLAUDE.md pointer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
jared
parent
876006f872
commit
e4048f5480
|
|
@ -37,6 +37,7 @@ Do NOT use `^(...)$` wrapping — Hyprland 0.51 rejects it as "Invalid rulev2".
|
|||
- `docs/hyprland/` — version-aware Hyprland config reference; update these when Hyprland is upgraded
|
||||
- `docs/synology.md` — DS218plus SSH alias, `/volume1/backup` map, restic repo commands, recovery notes
|
||||
- `docs/vps-inventory.md` — OVH VPS (`ovh-vps`) access notes; old Hyperthrive DO VPS deleted 2026-06-24 (historical notes retained)
|
||||
- `docs/incidents.md` — dated incident log (diagnosed-and-fixed issues): symptom, root cause, ruled-out, fix, follow-up
|
||||
|
||||
## Project status
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
# Incident log
|
||||
|
||||
Dated entries for diagnosed-and-fixed system incidents on this machine.
|
||||
Newest first. Keep entries factual: symptom, root cause, what was ruled out,
|
||||
fix applied, and any follow-up.
|
||||
|
||||
## 2026-06-24 — Chrome repeatedly crashing (SIGBUS), corrupt Favicons block on single-copy Btrfs
|
||||
|
||||
**Symptom**
|
||||
|
||||
Google Chrome crashed within seconds of launch, repeatedly. Three crashes in
|
||||
three minutes on 2026-06-24 (13:15, 13:16, 13:17), all signal **SIGBUS**.
|
||||
History of crashes back to April (mixed SIGTRAP / SIGILL / SIGSEGV / SIGBUS),
|
||||
18 minidumps total.
|
||||
|
||||
**Root cause**
|
||||
|
||||
A single corrupt data block at offset **942080** of
|
||||
`~/.config/google-chrome/Profile 2/Favicons` (a SQLite DB, inode 141150,
|
||||
btrfs root 257). Chrome `mmap()`s the file on startup; the kernel raises SIGBUS
|
||||
when it cannot fault in the bad page.
|
||||
|
||||
Each SIGBUS coredump correlated to the second with a kernel log line:
|
||||
|
||||
```
|
||||
BTRFS warning: csum failed root 257 ino 141150 off 942080 csum 0x0858109c expected 0x0858109e mirror 1
|
||||
```
|
||||
|
||||
Same single-bit flip every time (`9c` vs `9e`). The volume is `Data, single`
|
||||
(no mirror), so Btrfs detects but **cannot self-heal**. `corruption_errs` was
|
||||
climbing (41 → 42). Disk `read` / `write` / `flush` `io_errs` were all 0 —
|
||||
silent at-rest corruption; the NVMe is not reporting hardware faults.
|
||||
|
||||
**Ruled out**
|
||||
|
||||
- **OOM** — 87 GiB RAM free, and SIGBUS ≠ SIGKILL.
|
||||
- **Disk full** — 5% used.
|
||||
- **Chrome version / update** — install dated 2026-06-20 predates the crashes;
|
||||
`rpm -V` clean.
|
||||
- **Profile / extension corruption.**
|
||||
- **Dual-GPU / Wayland stack** — GPU libs in the dump were merely mapped; the
|
||||
`gpu_channel.cc Buffer Handle is null` line was a downstream symptom logged
|
||||
~2s after the SIGBUS.
|
||||
|
||||
**Fix applied (2026-06-24)**
|
||||
|
||||
Confirmed Chrome not running, then deleted the regenerable cache files
|
||||
`Favicons` and `Favicons-journal` from `Profile 2/`. Chrome regenerates these on
|
||||
next launch. Verified gone.
|
||||
|
||||
**Scrub result (2026-06-24 13:28)**
|
||||
|
||||
`sudo btrfs scrub start -B /home` finished in 0:55, scanned 79.57 GiB.
|
||||
**Error summary: `csum=2`, Corrected 0, Uncorrectable 2.** The corruption is
|
||||
**not** isolated to the Favicons file — two further uncorrectable blocks, in
|
||||
two different subvolumes, both regenerable/reinstallable:
|
||||
|
||||
| File | Subvol | Action |
|
||||
|------|--------|--------|
|
||||
| `~/.cache/google-chrome/Profile 1/Cache/Cache_Data/5f188fe6012a3cdc_0` | home (root 257) | Deleted (regenerates) ✅ |
|
||||
| `/usr/share/help/fr/gdm/index.docbook` | root (root 259) | Owned by `gdm-49.2-2.fc43`; restore via `sudo dnf reinstall gdm` |
|
||||
|
||||
`corruption_errs` 44; `read`/`write`/`flush` `io_errs` 0.
|
||||
|
||||
**Remediation + verification (2026-06-24 13:38–13:42)**
|
||||
|
||||
- Deleted the Chrome cache block (`rm`, regenerates).
|
||||
- Restored the gdm file: `sudo dnf reinstall gdm`.
|
||||
- **SSD health is clean** — `sudo nvme smart-log /dev/nvme0n1`:
|
||||
`critical_warning 0`, `media_errors 0`, `percentage_used 0%`. The drive has
|
||||
logged **zero** media errors at the hardware level → a *failing SSD* is
|
||||
unlikely; corruption reached good flash from upstream (RAM/bus).
|
||||
- **Second scrub (13:41)** still reports `csum=2` uncorrectable — but at the
|
||||
**exact same two physical blocks** as the first scrub (`logical 1754923008`,
|
||||
`logical 21439315968`), and this time **with no resolvable path**. The live
|
||||
files now point at fresh extents; the corrupt extents are **orphaned dead
|
||||
blocks** (not snapshot-pinned — `snapper`/`timeshift` not installed).
|
||||
|
||||
**Assessment**
|
||||
|
||||
Same two static blocks across two scrubs 13 min apart = corruption is **static,
|
||||
not actively spreading** (no new blocks appeared). Combined with the clean SSD
|
||||
SMART, this most likely stems from a **single past corruption event** rather
|
||||
than an actively-failing component. The crash-causing live files are fixed;
|
||||
the residual scrub errors affect no live file.
|
||||
|
||||
**Outstanding / follow-up**
|
||||
|
||||
- **Re-scrub in a day or two** (`sudo btrfs scrub start -B /home`). If the two
|
||||
orphaned blocks have cleared (reclaimed) and no *new* errors appear → fully
|
||||
resolved. **New** blocks appearing = corruption is ongoing → back up now and
|
||||
run memtest.
|
||||
- **Run memtest86+** (Fedora GRUB boot entry) for confidence — scattered
|
||||
multi-file corruption with zero drive I/O errors is the classic bad-RAM
|
||||
signature, even if currently static.
|
||||
- The `corruption_errs` counter will not drop on a single-copy volume — expected.
|
||||
Loading…
Reference in New Issue