[Resolved: local plugin] Unread fetch bodies exhaust renderer FDs and freeze Linux UI

[Ahrunda]

Update: root cause found in local notification plugin

The renderer exhausted its 1024 file-descriptor limit because the local dsh-notify-kde plugin did not read/cancel repeated no-store fetch responses. Of 983 retained 64 KiB regions, 979 contained {"ok":true}. In an isolated app using this exact Electron 44.7.0 binary with GPU disabled, the original client reached 1024 FDs after 1000 heartbeats; explicitly cancelling unused bodies kept the fixed client at 30–31 FDs through 2500 heartbeats. The font wait below is a downstream symptom; no DSH font-algorithm change is proposed. Full plugin tests: 47 passed. The fix has now been reloaded into the actual desktop app, with short-run body cleanup/FD stability verified; multi-hour production validation remains pending.

Original investigation follows for reference.

---

Summary

Linux desktop repeatedly becomes completely unresponsive while the separate DSH host can continue and finish an existing model turn. A live hang in 0.2.2-rc.1 / Electron 44.7.0 was symbolicated using the matching official Electron symbols: the renderer main thread is indefinitely waiting in font_service::internal::FontServiceThread::FallbackFontForCharacter while shaping text. The outstanding lookup was U+2461 (②), locale zh-CN.

This is a report of a captured hang, not a claim that typing ② alone reliably reproduces it or that the deeper cause of the missing completion has been identified.

Reproduction

1. Start DSH desktop on Arch Linux / KDE Wayland and use existing conversations containing Chinese text and numbered symbols.
2. Continue normal conversation and scroll/read responses.
3. Intermittently the entire page stops updating/responding. The desktop process tree remains alive. Restarting the app restores responsiveness temporarily.

There is not yet a standalone deterministic reproducer. The problem was observed before adding diagnostic instrumentation and has occurred repeatedly across restarts. Two independently captured hangs (Nov 10 and Nov 11) have matching ELF-relative PCs at the font-fallback wait.

The fully investigated Nov 11 instance was started with:

--remote-debugging-port=9333 --enable-logging=stderr

Diagnostic caveat: that instance also had a page probe wrapping fetch / WebSocket listeners and recording timer/rAF heartbeats. Third-party plugins were enabled; a clean-profile reproduction has not yet been established. This report does not rule out a plugin or embedder lifecycle interaction.

Current behavior

• Around 13:13:28 CST, page heartbeats stop and page-target CDP Runtime.evaluate stops responding. The last heartbeat at 13:13:27.716 had rafAgo=5ms, visibilityState=visible, and focus. Thus this particular capture is not merely an rAF pause in a hidden window.
• The host continued executing the current turn and recorded turn/end with reason.kind=completed at 13:15:27.
• Native stack, renderer main thread (ELF-relative return PCs; official symbols, not nearest-export guesses):

0x03b0015f base::WaitableEvent::TimedWaitImpl
0x03affa2a base::WaitableEvent::TimedWait
0x03afb307 font_service::internal::FontServiceThread::FallbackFontForCharacter
0x049a21ae content::WebSandboxSupportLinux::GetFallbackFontForCharacter
0x049a1c0c blink::FontCache::PlatformFallbackFontForCharacter
0x049a1724 blink::FontCache::FallbackFontForCharacter
0x0447e242 blink::FontFallbackIterator::Next
0x044794e6 blink::HarfBuzzShaper::ShapeSegment
0x04470aa6 blink::HarfBuzzShaper::Shape
... Blink inline / Flex / Grid layout ...

Symbol matching and live-memory investigation

• ELF build ID: 6d9c8e1bbe821f8226585947aa0d54074711a758.
• Official archive: https://github.com/electron/electron/releases/download/v44.7.0/electron-v44.7.0-linux-x64-symbols.zip
• Breakpad MODULE: Linux x86_64 1B8E9C6D82BE821F26585947AA0D54070 electron, matching the ELF ID after GUID byte-order conversion.
• Disassembly at function entry 0x03afb0c0 saves the character argument with mov %esi,-0x3c(%rbp). Reading that location in the frozen frame gives 0x2461. The locale is the libc++ short string zh-CN.
• Disassembly at 0x03afb2f2 loads 0x7fffffffffffffff before the wait. Despite the TimedWait name, this invocation is an unbounded wait.
• The renderer's FontServiceThread object has one entry in pending_waitable_events_. The entry points to exactly the stack done_event on which the renderer main thread is waiting. Object layout was checked against constructor/Impl disassembly. This establishes an outstanding completion, not why it was lost/delayed.
• A privileged eu-stack capture of all browser-process threads was also symbolicated. The UI/IO threads were in their event loops and worker threads were waiting for work. That sample did not show an executing/blocking fontconfig call. Therefore a fontconfig mutex deadlock is not established by this report.
• The prior Nov 10 hang has the same normalized 0x03afb307 / 0x049a21ae return PCs.
• System fc-match ':charset=2461' returns DejaVu Sans immediately; several installed fonts cover the character. This is not simply an absence of a font containing U+2461, although it does not validate Electron's embedded font-service path.

The full raw captures remain local because they contain process addresses and paths. The relevant normalized frames are included above; additional sanitized diagnostics can be supplied.

Expected behavior

A failed/unavailable fallback-font lookup should not leave the renderer main thread blocked indefinitely. The UI should remain usable, even if an individual character must temporarily render as a missing glyph.

Requested triage:

• Investigate why this outstanding font-service request never completes and why the completion/disconnect path does not wake the waiter.
• Check DSH's Electron/font-service lifecycle and whether a newer supported Electron runtime changes this behavior.
• A naive timeout in this bridge is unsafe: callbacks retain stack output pointers, so any timeout/cancellation fix must also address callback lifetime.

I have not verified that updating Electron, changing UI fonts, rebuilding font caches, or disabling the GPU fixes this hang. No such fix should be inferred from the stack alone.

Environment

• DSH desktop: 0.2.2-rc.1 (Arch package 0.2.2rc.1-1); earlier repeated freezes also occurred on 0.2.2-alpha.2.
• Electron 44.7.0; Chromium 152.0.7977.130; V8 15.2.124.28.
• Arch Linux x86_64; Linux 7.2.14-zen1-1-zen; KDE Plasma Wayland; AMD graphics.
• fontconfig 2.18.3-2; freetype2 2.15.0-1; Mesa 26.2.6-1; GTK3 3.24.52-2; glibc 2.44+r50+g1848099f063e-1.
• Multiple third-party plugins enabled; diagnostic CDP port/logging/probe as described above.
• No deterministic reproduction on a stock Electron app or latest Electron patch release yet.

[Ahrunda]

A second live hang was captured today around 14:22:56 CST, after restarting the desktop app. Two useful differences from the first capture:

• The blocked font-fallback character is now U+90E8 (部), an ordinary Chinese character, rather than U+2461. The matching 0x03afb307 → 0x049a21ae frames and RBP links were checked against the same official symbols/build ID. This is not evidence for a deterministic single-character reproducer.
• There is a recorded prelude: the last rAF was approximately 14:22:50.668; timer heartbeats and some input handling continued for about six seconds with visibilityState=visible and focus true. Some fetches still completed through 14:22:52.992. The page then stopped responding entirely. The user reported misaligned rendering and areas disappearing as the pointer moved over them before the full freeze. No screenshot of the user's desktop was taken.

Additional native / Mojo investigation

The font request has progressed further than merely a posted task:

• FontServiceThread::pending_waitable_events_ contains one event, matching the blocked main thread's stack done_event.
• Its InterfaceEndpointClient identifies itself as font_service.mojom.FontService. The async responder map contains exactly one entry: request ID 321, next ID 322, message ordinal 0x2c07ebf0. The current binary's FontServiceProxy::FallbackFontForCharacter loads precisely that ordinal.
• The retained response callback's bind state contains both the same FontServiceThread object and the same stack event. encountered_error_ is false. Field offsets were checked against the current build's disassembly, including SendMessageWithResponder's map insertion and connection-error check.
• The corresponding Chromium send path inserts the async responder after the controller accepts the outgoing message. Thus the Impl ran and the matching callback is still owned by Mojo. This does not establish whether the peer received the request or sent a response.

Full GPU and browser native stacks were obtained with eu-stack and symbolicated:

• GPU main: MessagePumpDefault::Run → RunLoop → GpuMain, waiting for an event-loop wakeup.
• Viz compositor: the same ordinary message-pump wait.
• Browser UI: GLib message loop; thread-pool workers waiting for work; Pango font thread waiting on its async queue.

These samples show neither a GPU driver/fence wait nor an executing/blocked fontconfig call. They cannot exclude a graphics fault preceding the samples. CDP reports ANGLE OpenGL / Mesa 26.2.6 on RX 9060 XT, with hardware compositing/rasterization enabled. No corresponding GPU reset/crash was found in the checked logs.

The model turn had completed at 14:21:36.621, before this freeze. Renderer memory was read through /proc without pausing it; the privileged GPU/browser stack captures were taken after confirming recent turns had ended.

The remaining investigation boundary is the request/response path between the sender/controller, browser font service, and renderer response dispatch. The earlier loss of rAF and subsequent loss of fetch completions should also be considered; the post-hang font stack alone does not explain the initial rendering corruption. No font/GPU/runtime workaround has been verified yet.

[Ahrunda]

Root cause found and a local fix reproduced: the notification plugin leaves fetch response bodies unread, exhausting renderer file descriptors. The font-service wait is a downstream symptom in the captured instance, not evidence of a missing glyph or a defect specifically triggered by ②.

Live renderer inventory:

• 1024 open FDs / soft RLIMIT_NOFILE 1024; browser, GPU and network processes were not exhausted.
• 990 shared-memory FDs; 983 regions are 64 KiB, and 979 contain {"ok":true}.
• The locally installed dsh-notify-kde client posts focus state every two seconds. Its focus/hello/result/consumed requests only attached .catch() and never read/cancelled the no-store JSON responses. The captured focus/result/consumed traffic is consistent with those retained bodies.

I isolated the actual plugin client in a small Electron app using a local custom protocol, with no DSH host, model, diagnostic page probe, or user data. Using the exact Electron 44.7.0 binary from this DSH installation, Xvfb, GPU disabled, and renderer nofile 1024/524288:

Client	Focus posts	Renderer FDs	Retained shared-memory FDs
Original	0 → 1000	31 → 1024	1 → 993
Fixed	0 → 2500	30 → 31	0 → 0

After exhaustion, forcing Chinese layout also timed out. That isolated timeout did not match the same fallback stack, so I am not presenting it as an identical-stack reproduction. It does reproduce and remove the resource accumulation seen in the live hang. Electron 44.10.2 also reproduced the original FD growth; a runtime update alone did not address the leak.

The local patch explicitly cancels unused bodies:

fetch(url, options)
  .then(response => response.body?.cancel())
  .catch(handleError);

Successful pending polls still parse JSON; unsuccessful polls also cancel their bodies. The plugin's full 47 tests pass; the new release checks fail against the old code. With the user’s approval, the frozen instance has now been fully restarted. The actual loaded client source contains the cancellation fix. In the first several minutes, the full DSH renderer remained around 48 FDs, with zero retained 64 KiB {"ok":true} response regions. This terminal launch inherited a higher nofile soft limit, so these live checks rely on FD stability and body cleanup; the controlled 1024-limit comparison is the isolated test above. Multi-hour production validation remains pending.

This corrects the direction of my initial investigation: I should have checked FD usage/limits before repeatedly interpreting the native wait stack. No change to DSH's font-selection code is proposed by this finding. Chromium's behavior on FD exhaustion may still merit separate robustness work; a related report is crbug 582417463.