# 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.