Fix Linux OOM: disable Blossom SHA-256 URL auto-detection

Commit 214c42b (v0.12.6) added auto-detection of content-addressed
Blossom URLs (64-hex SHA-256 paths) as <img> elements. Blossom is
widespread in modern Nostr feeds — every feed page started rendering
3-5x more <img> elements. Combined with WebKitGTK's weak decoded-
bitmap eviction, feed scrolling grew the WebKit web process to
8-12 GB and triggered WebKit's self-kill threshold with:

  Unable to shrink memory footprint of process (9022 MB) below
  the kill threshold (8192 MB). Killed

Disable BLOSSOM_URL_REGEX in parseContent(). Real Blossom images
shared via standard upload flows (with proper extensions) still
render. Proper reintroduction (HEAD request + Content-Type
validation, or known-server whitelist) planned for v0.12.9.

Also restore feed depth caps to pre-crisis values now that memory
is under control:
  - MAX_FEED_SIZE 30 → 200 (v0.12.6 baseline)
  - fetchFollowFeed limit 30 → 100
  - fetchGlobalFeed fetch 80 → 100
  - Following tab slice 30 → 100

The earlier 30-caps were themselves OOM firefighting that shipped
in v0.12.7 and were no longer needed.

Memory verified 2026-04-16: oscillates 1.1-1.6 GB across all tabs
(Global / Following / Trending / Media / profile / thread) under
heavy use with embedded relay enabled. No crashes. Elastic cache
behaviour rather than monotonic leak — memory spikes briefly on
content loads and reclaims within seconds.

See private_docs/WEBKIT_OOM_INVESTIGATION.md for the full
investigation (4 days of chasing symptoms before finding the
one-line regex as the real cause).
This commit is contained in:
Jure
2026-04-16 17:55:06 +02:00
parent 8b5fdc0720
commit bc4c72d6a0
6 changed files with 15 additions and 12 deletions
+4 -4
View File
@@ -71,10 +71,10 @@ jobs:
### v0.12.8 — Fix Linux OOM crash
- **Fix Linux memory crash** — Vega no longer crashes or freezes the OS on Linux; memory now plateaus at ~950MB during heavy use instead of spiking to 32GB+
- **Following feed capped** — following feed was rendering up to 80 notes (vs. 30 for global), causing 4GB+ spikes on media-heavy accounts; now capped at 30
- **WebKit rendering fix** — switched to `WEBKIT_FORCE_SOFTWARE_RENDERING=1` which fixes the blank window issue on Hyprland/Wayland while keeping memory low
- **Notification fetch dedup** — `fetchNotifications` was firing 3× in the first 8 seconds of login; now fires once and the first background poll is delayed to 90s
- **Fix Linux memory crash** — Vega no longer crashes on Linux. Memory now oscillates at ~1.11.6 GB during heavy use instead of climbing to 812 GB. Root cause traced to v0.12.6: the Blossom SHA-256 URL auto-detection regex caused 35× more `<img>` elements per feed page, which combined with WebKitGTK's weak bitmap eviction pushed the WebKit process past its 8 GB self-kill threshold. Blossom auto-detection is temporarily disabled pending proper validation in v0.12.9.
- **Feed depths restored** — the v0.12.7 OOM firefighting that slashed follow/global feed limits to 30 is reverted; follow feed now fetches 100 and global caches up to 200, matching pre-crisis v0.12.6 behavior.
- **WebKit rendering fix** — `WEBKIT_FORCE_SOFTWARE_RENDERING=1` keeps the Wayland compositor path intact on Hyprland.
- **Notification fetch dedup** — `fetchNotifications` was firing 3× in the first 8 seconds of login; now fires once and the first background poll is delayed to 90s.
### v0.12.7 — Upload Fixes