Repository navigation
memory.leak-suspect: desktop webview grows about 50 MB/h without levelling #96
Description
Summary
The Linux desktop's webview process (WebKitWebProcess, which runs the BiBCode UI) kept growing for the whole of a twelve-hour session on v0.9.1: 122 MB of private memory just after start, 750 MB twelve hours later, with no plateau. The profiler raised memory.leak-suspect for it five times. #79 noted the same process at 22 MB/h on v0.9.0 but left it out because it was flat then.
Environment
| Field | Value |
|---|---|
| BiBCode | v0.9.1, desktop (AppImage) |
| OS | Linux 7.2 (Arch-based), x86_64, WebKitGTK webview |
| Mode | local UI; a remote macOS client was also connected |
| Finding | memory.leak-suspect-6b0bedc9a176: warn, seen 5 times from 2026-10-11T23:09:51Z to 2026-10-13T18:41:44Z |
| Fingerprint | 6b0bedc9a176 |
| Capture | native dumps available, OS crash records available |
Evidence
- Latest finding: slope 24.1 MB/h at 552 MB private, metric
private. process.samplefor one webview process since 11:25Z, private memory per hour: 122 MB (11Z), 269 (12Z), 286 (13Z), 289 (14Z), 318 (15Z), 342 (16Z), 498 (17Z), 536 (18Z), 560 (19Z), 658 (20Z), 750 MB (23:03Z).
Suspected source
Not identified. Candidates to check first:
packages/client-runtime/src/state/threads.ts: thread state kept per subscribed thread; long agent threads hold tens of thousands of activities.- The v0.9.1 thread stream replaced the whole thread on every event (fixed by thread patches in PR v0.9.2: remote latency, PR panel, watcher loop, delivery and update fixes #92), so each event allocated a new copy of a large thread; growth that tracks agent activity would point there.
Reproduction
- Run the Linux desktop with the profiler on.
- Keep one or more long agent threads active for several hours.
- Watch
process.sampleforWebKitWebProcess: private memory rises in steps during agent activity and does not return.
Root-cause hypothesis
Retained client state grows with thread history (activities and messages of every thread opened in the session), and whole-thread replacement on every event raises the peak. Confidence: low, because no heap snapshot was taken and the growth could partly be legitimate data.
Suggested fix direction
Take a JavaScript heap snapshot (WebKit Web Inspector) at the start and after a few hours to find what is retained. Bound per-thread state in the client (window old activities, release threads that are no longer open), and recheck the slope once thread patches ship.
Activity
mubeda commentedon Oct 14, 2026
New occurrence of
memory.leak-likely-c023666f632d(profiler fingerprintc023666f632d), the same webview process as this issue:What is new: the detector moved from
memory.leak-suspect(warn,6b0bedc9a176) tomemory.leak-likely(error): the growth is a straight line (r² 1.0), not a step that settles.process.samplefor the same process (pid unchanged since 2026-10-13T11:25Z), private memory: 750 MB (2026-10-13T23:03Z), 1,059 MB (07Z), 1,093 MB (08Z), 1,134 MB (09Z), 1,138 MB (10Z, partial hour).v0.9.2 (thread patches) shipped after these samples; the slope after updating will show how much of the growth came from whole-thread replacement.
fix(desktop): read the local backend topology from cache instead of I…
mubeda commentedon Oct 14, 2026
A macOS data point for the webview memory in this issue. It does not confirm a leak.
What is new: a macOS observation, made with
psandfootprintbecause the Profiler cannot see this process. One WebContent process, up since 2026-10-14T10:19Z:RSS rose by about 160 MB in 2 h 16 min, but the physical footprint fell by 258 MB, so the RSS growth is mostly reclaimable memory, not retained heap. During this window the webview was also CPU-bound in Base UI's per-commit label scan (#106). Re-measure after #104 lets the Profiler sample this process and #106 removes the CPU load.
fix(web): stop Base UI scanning the page for labels after every render (
merge: release v0.9.3 (PR #108)
mubeda commentedon Oct 15, 2026
Shipped in v0.9.3.
The macOS measurement in this thread showed the growth was mostly reclaimable memory rather than memory the webview holds. Closing for v0.9.3; if the webview's private memory still climbs on v0.9.3 (Linux or macOS), please open a new issue against v0.9.3 with the profiler's
memory.leak-*finding.mubeda commentedon Oct 15, 2026
New occurrence of
memory.leak-likely-9be6f589813f(profiler fingerprint9be6f589813f), the macOS webview on the release that closed this issue:What is new: on 0.9.3 the Profiler samples the macOS webview (#104), and its first verdict is
memory.leak-likely(error), so the growth this issue tracked is not resolved on macOS. The growth comes in steps after activity, not as a steady climb.process.samplefor WebContent pid 54456 (app started 11:49Z), private memory: 234 MB (a4b7f89f-2), flat at about 330 MB from 12:10Z to 12:43Z (a4b7f89f-93to-162), 631 to 658 MB by 12:52Z (-212,-217), 643 MB at 13:24Z (-373), 778 to 793 MB at 13:31Z to 13:32Z (-468,-475), 922 to 955 MB at 13:45Z to 13:52Z (-606,-657), and 840 MB at 14:03Z (-734). RSS went from 235 MB to 1,755 MB. Profiler CPU stayed under 3 %, so this is not the rpc.slow: Base UI label lookup on every render saturates the macOS webview #106 CPU load.rpc.bytes. One 6.51 MBorchestration.subscribeThreadmessage in the slot ending at 13:23Z (a4b7f89f-362) precedes the 13:24Z step. Threeprojects.listEntriesmessages of 2.49 MB each in the slot ending at 13:33Z (a4b7f89f-510) precede the 13:31Z step. That listing is the same full re-read as memory.leak-suspect: Files panel re-reads the whole entry list on every change #111, but at twice the size per message. The 12:47Z to 12:52Z step has no large push in its slot.subscribeDiscoveredLocalServerssent about 280 messages per 5-minute slot (a4b7f89f-437,-499), about one a second, which is chatty but small.footprintshowed 614 MB at 14:39Z, down from the 935 MB peak, with RSS at 1.85 GB. Part of the growth is reclaimable, but private memory still climbed about 600 MB in 2 hours.Suspected source: client state that grows with each large message, namely full thread snapshots from
orchestration.subscribeThreadand full entry lists fromprojects.listEntries(apps/web/src/components/files/FileBrowserPanel.tsx:217, see #111). Confidence: low, because no WebKit heap snapshot has been taken.Suggested next step: take a Web Inspector heap snapshot of the desktop webview before and after opening a large thread and the Files panel. Consider reopening this issue for macOS.
mubeda commentedon Oct 15, 2026
Reopening: on 0.9.3 the Profiler now samples the macOS webview (#104), and it reports
memory.leak-likely(fingerprint9be6f589813f, error, about 254 MB/h). See the comment above for the evidence.mubeda commentedon Oct 16, 2026
Follow-up in v0.9.4: reconnecting to a long thread no longer keeps another full copy of the thread in the web view (unchanged parts of a resent thread are reused). macOS Web Inspector confirmation is still outstanding.
docs: record the v0.9.5 macOS device-preview, #119 and #96 run, and n…
mubeda commentedon Oct 19, 2026
New occurrence of
memory.leak-suspect-91f0d582380a(profiler fingerprint91f0d582380a):What is new: WebContent private memory raised a 126.2 MB/h suspect warning after the 0.9.4 thread-copy fix. In this app run it rose overall from 962 MiB at 14:30Z to 1,326 MiB at 17:01Z, with substantial sawtooth. The minimum in the first 30-minute window was 945 MiB; in the last completed 30-minute window it was 1,111 MiB. The peak was 1,501 MiB. This is continued growth in the sampled floor, but the allocating component is not yet identified.
1b24857d-713process.sample: WebContent 962 MiB private at 14:30:00Z.1b24857d-1138finding: the suspect warning at 16:06:00Z, when evidence recorded about 1,075 MiB private.1b24857d-1428process.sample: WebContent 1,326 MiB private at 17:00:58Z.ok, dropped events were 0, and no new crash dump was present.The iOS and Android emulator attempts ended by 14:18Z, almost two hours before this finding. The profile does not establish a causal link. Hypothesis: client or WebKit state retained during continued UI use; confidence low without a Web Inspector heap/profile capture.
docs(testing): macOS measurements for #119 and #96 (#134)
docs(testing): #134 Layers count and post-reconnect heap snapshots
docs(testing): #96 heap after the minimap fix (#134)
merge: device, macOS and Git fixes (#146) and v0.10.2 release prepara…
mubeda commentedon Oct 22, 2026
New occurrence of
memory.leak-likely-c023666f632d(profiler fingerprintc023666f632d):What is new: the WebKitGTK web process still grows on 0.10.2 on Linux, measured on the private metric (
RssAnon + VmSwap), so it is not the RSS overstatement described in #159.WebKitWebProcess, metricprivate, slope 23.6 MB/h, r² 0.87, 618 MB private at detection.process.sample, same process over 24 h (1,440 samples): 424 MB (2026-10-21T14:04Z) to 795 MB (2026-10-22T14:03Z); minimum 424 MB, maximum 967 MB. Peaks partly come back down, but the floor rose by about 370 MB in a day.memory.leak-suspect-6b0bedc9a176(the same web process, 11 MB/h, last seen 2026-10-21T13:29Z) andmemory.leak-suspect-23b411a46199(WebKitNetworkProcess, 12 MB/h, first seen on 0.10.0, last seen 2026-10-21T18:41Z).mubeda commentedon Oct 22, 2026
Diagnosis of the 0.10.2 Linux occurrence above. The webview's growth has two regimes, now tracked separately:
mubeda commentedon Oct 27, 2026
New occurrence of
memory.leak-suspect-91f0d582380a(profiler fingerprint91f0d582380a):What is new: on macOS the WebKit WebContent process still grows on 0.11.0, at 213.8 MB/h on the private metric, reaching 1.36 GB private at detection.
com.apple.WebKit.WebContent, metricprivate, slope 213.8 MB/h, 1,357,731,864 private bytes at detection.process.sampleat 2026-10-27T19:29Z (0.11.0, just before the upgrade): the same process at 1,241 MB private and 3,619 MB RSS while idle (CPU 0.1 %).mubeda commentedon Oct 27, 2026
New occurrence of
memory.leak-suspect-6b0bedc9a176(profiler fingerprint6b0bedc9a176):What is new: the suspect fires on 0.12.0, after #167 and #168 closed, within about 75 minutes of the app's start. The curve is the step regime from the 2026-10-22 diagnosis, not a steady climb, and it is too short to call a leak yet.
process.sampleforWebKitWebProcess(one pid since the 19:34Z start), private memory:dfda5aa3-37(19:36Z) 365 MiB,dfda5aa3-206(19:43Z) 346 MiB,dfda5aa3-487(20:08Z) 386 MiB,dfda5aa3-716(20:34Z) a burst to 657 MiB,dfda5aa3-737(20:36Z) 397 MiB,dfda5aa3-886(21:06Z) 397 MiB.dfda5aa3-817findingat 20:50:42Z.The floor rose from 346 MiB to 397 MiB in about 80 minutes. It steps up after bursts of activity and once fell back (393 to 353 MiB at 20:00Z), and it has been flat for the last 30 minutes. Confidence that 0.12.0 still retains memory per burst: low. I will add the next hours' samples here if the floor keeps stepping up.
mubeda commentedon Oct 27, 2026
New occurrence of
memory.leak-likely-9be6f589813f(profiler fingerprint9be6f589813f):What is new: 0.12.0 still leaks. Two hours after a fresh start, the macOS WebContent process raised
memory.leak-likelyat 463 MB/h while the app sat idle, with no thread or orchestration activity.Finding evidence:
com.apple.WebKit.WebContent, metricprivate, slope 463.3 MB/h, r² 0.89, 1,393 MB private at detection.process.sample, same web process after the 0.12.0 start (120 samples, 2026-10-27T19:46Z to 21:45Z, one per minute):The process held flat for about 30 minutes, then its private memory climbed roughly 530 MB/h from 20:16Z. Over the same window RSS fell, so pages are being compressed rather than freed.
The only traffic in those two hours was background polling: 75
server.refreshProviderUsagecalls (about one every 96 s, several taking 1.2 to 15 s on the server), periodicserver.getProcessDiagnostics,server.getProviderUsage,previewAutomation.focusHost,vcs.refreshWorktreeCatalog,subscribeVcsStatusSummaryandsubscribeDiscoveredLocalServerspushes, and 225 profiler client batches. Suspects, in that order: the provider-usage refresh loop and the diagnostics polling, the idle path Unfocused desktop polls diagnostics every 2 s and gets 1 Hz unchanged pushes #168 targeted.Related on the same machine:
memory.leak-suspect-91f0d582380a(same process on 0.11.0, 214 MB/h, reported above).mubeda commentedon Oct 28, 2026
New occurrence of
memory.leak-suspect-91f0d582380a(profiler fingerprint91f0d582380a):What is new: on the same 0.12.0 web process as the
memory.leak-likelycomment above, the overnight data changes the picture. The earlier climb to about 1.4 GB was mostly reclaimed, and what remains is a slow creep of about 15 MB/h.Finding evidence:
com.apple.WebKit.WebContent, metricprivate, slope 15.0 MB/h, 854 MB private at detection.process.sample, same process (298 samples, 2026-10-27T23:46Z to 2026-10-28T04:45Z):Minimum 745 MB, maximum 1,253 MB. Private memory fell from 1,414 MB (2026-10-27T21:31Z) to about 745 MB by 23:46Z without a restart.
In this window the profiler recorded no
client.batch,client.requestorserver.refreshProviderUsageevents, onlyprocess.sample,rpc.bytesandworktree.audit. The client was apparently suspended or not polling, and the steep growth stopped with it. That supports the polling suspects named above, and suggests much of the 463 MB/h was garbage the web process reclaimed later rather than memory that is never freed. The residual 15 MB/h with no client activity is the part still unexplained.mubeda commentedon Nov 2, 2026
New occurrence of
memory.leak-suspect-6b0bedc9a176(profiler fingerprint6b0bedc9a176):What is new: the
WebKitWebProcessstill grows on 0.14.0, more slowly than the 55 MB/h last reported on 0.12.0.process.sampleprivate MB, 15-minute spacing: 258 at 08:00Z (0.13.0), 276 at 10:14Z after the 0.14.0 restart, 283 at 12:14Z, 291 at 13:29Z, 297 at 15:14Z, 313 at 17:29Z.