[Bug]: Linux: host process continuously grows anonymous memory while idle (WebKitGTK)

[Corebarn]

Description

On Linux, a Ryn 0.32.0 application using WebKitGTK continues to grow memory while its window is open and completely idle. In one clean idle interval, the main host process gained about 5 MiB of anonymous/private memory in 60 seconds. The WebKit web and network subprocesses remained effectively flat during the same interval.

The test application has also been observed rising from about 160 MB at startup to about 228 MB after one minute without user interaction. Repeated launch/open/close experiments showed continued native-memory growth rather than a stable plateau.

The equivalent Windows build of the same application, which uses WebView2, settles at about 26 MB after startup. That makes shared application state or ordinary managed .NET retention unlikely and points toward the Linux host-side Ryn/Saucer/GTK event or rendering path.

The strongest new observation is that the growth is visibility-dependent: while the window is visible and untouched, the host process uses roughly 5-12% CPU while anonymous memory rises. Moving the tiled window fully outside the visible monitor area under niri drops host CPU use to about 0%, after which memory stabilizes or is reclaimed instead of continuing to grow. Bringing the window back into view resumes both the CPU use and the memory slope. That coupling points to active rendering/compositing or frame scheduling in the Linux webview path rather than a passive background leak or an available-memory effect.

Environment

Ryn packages	0.32.0 (Ryn and plugins)
Application runtime	.NET 10, x86-64
OS	CachyOS Linux, kernel 7.2.0-1-cachyos
Session / compositor	Wayland / niri
WebKitGTK	webkitgtk-6.0 2.52.6-1
GTK	gtk4 4.22.4
GPU / driver	NVIDIA GeForce RTX 4070 / nvidia-utils 610.57.04
Host memory	30 GiB RAM, about 8.9 GiB available during measurement; 62 GiB swap
Windows comparison	Same application and frontend using Ryn/WebView2 settles at about 26 MB after roughly 10 seconds

Visibility dependence

State	Host CPU	Memory trend
Visible, idle	roughly 5-12%	steady anonymous growth (e.g. +5,004 KiB over 60 s above)
Fully off the visible monitor (occluded)	about 0%	stabilizes; memory reclaimed rather than growing

The visible-state growth repeats across measurement sessions, and the occluded state stops both CPU use and growth — the process does not keep allocating in the background while nothing is being painted.

Diagnostics performed

Managed-memory evidence

Repeated launch/open/close measurements compared process memory with the .NET managed heap:

• Managed GC heap stayed around 1.6-1.7 MiB while host anonymous memory grew by tens of MiB across cycles.
• Thread count remained stable at about 55.
• A source audit found no retained launched-application object, accumulating event subscription, or unbounded application collection explaining the growth.

Temporary System.Diagnostics.Process wrappers found during that audit were explicitly disposed. That fixed real native handle ownership defects but did not stop the observed growth.

Optional application integration disabled

As a diagnostic, the optional application integration (external application discovery/import) was completely disabled on Linux: the module was not loaded and its IPC surface was removed before any event handlers could attach. The major Linux/Windows memory difference remained, so that integration is not the source.

Frontend lifecycle audit

The frontend cleanup paths were audited for Ryn IPC subscriptions, DOM listeners, Vue watchers, intervals/timeouts, and session callbacks. Explicit cleanup exists for the long-lived listeners and timers, and repeated initialization/detachment cycles did not reveal a recurring idle allocator or an unbounded collection.

Process split

The WebKit web and network subprocesses were stable over the measured idle minute; growth was concentrated in the main .NET/Ryn host process. This does not look like a growing JavaScript heap in WebKitWebProcess.

Visibility dependence (strongest evidence)

While the window is visible and untouched, the host process uses roughly 5-12% CPU while anonymous memory rises. Moving the tiled window fully outside the visible monitor area under niri (fully occluded) drops CPU use to about 0%, after which memory stabilizes or is reclaimed rather than continuing to grow; returning the window to view resumes both.

This distinguishes an active paint/frame/compositor path from a passive leak or an available-memory effect:

• Available system memory does not change when the window is moved off the visible monitor, so growth is tracking render activity, not allocator or page-cache policy reacting to memory pressure.
• A passive allocation leak (managed or native) would keep allocating whether or not the window is visible; here the growth stops when nothing is being composited.
• Near-zero CPU while occluded, plus stabilized or reclaimed memory, is the signature of a workload tied to visible composition: when there is nothing to paint, the frame/compositor loop idles and the resources it would have used are released.

The correlation strongly implicates active rendering/compositing or frame scheduling in the Linux webview path, but it does not prove which component performs the recurring work; a native allocation stack profile is still required for final attribution.

Available system memory

The Linux host had about 8.9 GiB available during measurement and substantial swap capacity. More available memory can change allocator trimming and cache retention, so absolute working-set values can differ across machines. It does not normally explain a repeatable, approximately linear increase in private anonymous pages while the application is idle.

Taken together, the strongest evidence is the visibility-coupled host behavior: host CPU and anonymous memory rise together while the window is visible, and both stop when it is fully off the visible monitor, while the managed GC heap and WebKit child processes remain stable throughout. That indicates recurring native work tied to visible rendering/compositing in the Linux webview path — allocations or retained allocator arenas inside native libraries loaded by the Ryn host — rather than Linux merely assigning extra file cache to the process or a steady background leak.

Suspected area

The evidence — especially the visibility dependence — points to the Linux host-side Ryn/Saucer/GTK/WebKit integration, with active rendering/compositing or frame scheduling as the recurring workload. The visible-versus-occluded behavior weights the frame/render path: an occluded window stops consuming CPU and stops growing, so the work is tied to visible composition rather than a steady background allocator. Potentially:

1. continuous frame scheduling or redraw invalidation while the window is visible;
2. GTK/WebKit host callbacks whose native payloads are not released;
3. frame/render invalidation or texture/surface allocations retained in the host process;
4. NVIDIA/EGL/GL resource accumulation associated with the embedded window;
5. allocator caching caused by a recurring native workload that should not exist while idle.

This does not prove which native component owns the allocation or the frame traffic; a native allocation stack profile is required for final attribution.

Operating system

Linux

OS version

CachyOS 7.0.2-1

Ryn version

0.30.0, 0.32.0

.NET version

10.0.111

Steps to reproduce

1. Build and run the test application on Linux with Ryn 0.32.0.
2. Leave the application window visible and do not interact with it.
3. Sample /proc/<pid>/smaps_rollup every 10 seconds for at least one minute.
4. Separately sample the WebKitWebProcess and WebKitNetworkProcess children.
5. Observe growth in the main application process while the WebKit children remain stable.
6. While the window is still visible and idle, also sample host CPU use alongside the memory slope.
7. Move the tiled window fully outside the visible monitor area (under niri, so it is not composited onto any visible output) and leave it untouched.
8. Sample the same metrics for at least one minute in the occluded state: CPU should drop to about 0% and the memory slope should flatten, with stabilization or reclamation instead of growth.
9. Move the window back into the visible area and confirm CPU use and memory growth resume.

The test application is a frameless Ryn window containing a Vue/Vite frontend. No external application needs to be launched to reproduce the idle growth.

Expected behavior

After normal WebKit/GTK startup and cache warm-up, an untouched Ryn window should reach a stable memory range. Private anonymous memory should not keep increasing by several MiB per minute indefinitely.

Actual behavior

Values below are from /proc/<pid>/smaps_rollup and are in KiB.

Process	Metric	Start	60 seconds	Delta
test application host	Anonymous	163,532	168,536	+5,004
test application host	Private Dirty	187,420	192,436	+5,016
test application host	PSS	277,736	282,650	+4,914
WebKit web process 1	Anonymous	109,856	109,968	+112
WebKit web process 2	Anonymous	90,060	89,652	-408
WebKit network process	Anonymous	24,796	24,796	0

During a later observation, the host process reported:

• VmHWM: 435,136 KiB
• VmRSS: 435,136 KiB
• RssAnon: 168,840 KiB
• RssFile: 251,892 KiB
• RssShmem: 14,404 KiB
• Threads: 55

Absolute RSS includes shared libraries and mapped files, so anonymous/private growth is the important signal.

Logs and output

Additional context

A small public minimal reproducer has not yet been prepared — the measurements above come from the full test application. Assistance reproducing with a minimal Ryn 0.32.0 Linux application containing one idle frameless webview would be welcome, in particular to inspect:

• whether the main loop continuously queues callbacks or invalidations;
• allocation/free balance around Saucer Linux event callbacks;
• GTK signal payload and closure ownership;
• WebKitGTK user-content-manager/message callback ownership;
• EGL/GL surface and texture lifecycle;
• whether hardware acceleration changes the anonymous-memory slope.

Useful comparison runs:

1. Empty static HTML versus the Vue frontend.
2. Normal decorated window versus frameless window.
3. Hardware acceleration enabled versus disabled.
4. NVIDIA versus Mesa/software rendering.
5. Ryn host without optional plugins versus the current plugin set.
6. heaptrack or equivalent native allocation profiling for a two-minute untouched idle window.

Most likely layer: Ryn/Saucer/GTK/WebKitGTK Linux host integration.

Confidence: moderate-to-high. Managed application retention, optional-integration discovery, and WebKit child-process heap growth have been directly reduced or contradicted by measurement. Exact native allocation ownership remains unproven until a native allocation profiler captures the growing stacks.

[Corebarn]

Renderer A/B diagnostic comparison (2026-08-29)

Six 180-second visible-idle runs of the same test application were compared under combinations of environment flags and Ryn's hardware-acceleration setting, to attribute the anonymous-memory slope to a rendering layer. The default source configuration (hardware acceleration enabled, no environment overrides) was restored immediately after the temporary HardwareAcceleration=false runs.

Methodology

• Six Debug launcher runs, each exactly 180 seconds, window visible and untouched throughout.
• /proc/<pid>/smaps_rollup sampled every 10 seconds for the host process.
• Slope (KiB/min) from the full 180-second anonymous delta; the warmed slope is the same delta computed over the 60-180 s window only.
• CPU is approximate: process user+system ticks over wall time, expressed as a percentage of one core.

Results (host process anonymous memory, KiB)

Configuration	Anonymous start	Anonymous end	Delta	Slope (KiB/min)	Warmed 60-180 s slope	CPU
Default (hardware acceleration on)	94,360	285,556	+191,196	63,732	64,820	94.26%
WEBKIT_DMABUF_RENDERER_FORCE_SHM=1	85,256	94,200	+8,944	2,981	3,774	28.39%
HardwareAcceleration=false	86,516	93,040	+6,524	2,175	2,722	39.08%
HardwareAcceleration=false + FORCE_SHM	90,436	95,616	+5,180	1,727	2,654	38.49%
__NV_DISABLE_EXPLICIT_SYNC=1	88,856	282,960	+194,104	64,701	65,710	87.27%
Explicit sync off + FORCE_SHM	83,188	88,336	+5,148	1,716	1,986	27.78%

Flags and options exercised

• Default source configuration: Ryn hardware acceleration enabled, no environment overrides.
• WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 (WebKitGTK 6.0): forces the DMA-BUF renderer to fall back to shared-memory buffers.
• HardwareAcceleration=false: a temporary Ryn source change disabling hardware acceleration. Reverted immediately after measurement; the default (accelerated) source configuration has been restored.
• __NV_DISABLE_EXPLICIT_SYNC=1: NVIDIA/EGL explicit-sync disable.
• WEBKIT_DISABLE_DMABUF_RENDERER=1 was intentionally not tested: on the current NVIDIA driver it carries a WebKitGTK crash risk, so WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 is the safe, tested workaround.

Interpretation

• Forcing SHM and disabling Ryn hardware acceleration each independently remove roughly 95-97% of the anonymous slope (default 63,732 KiB/min → 2,981 with FORCE_SHM; → 2,175 with HardwareAcceleration=false).
• Combining them adds little or no material memory benefit (1,727 KiB/min), so both switches are believed to land on the same DMA-BUF path.
• Disabling NVIDIA explicit sync alone does not improve the slope (+194,104 KiB, 64,701 KiB/min — within noise of the default), and the combined "explicit sync off + FORCE_SHM" result is fully explained by FORCE_SHM.
• The dominant allocation owner is therefore the accelerated WebKitGTK DMA-BUF rendering/import/texture lifetime, not explicit-sync behavior; the exact per-allocation ownership inside that layer is not claimed.
• CPU stays around 38-39% with hardware acceleration off versus about 28% with FORCE_SHM even though both stabilize memory, so the remaining CPU cost is not solely allocation-driven.

Suspected area

Effectively confirmed by the renderer A/B comparison. Forcing WebKitGTK's DMA-BUF renderer to shared-memory buffers (WEBKIT_DMABUF_RENDERER_FORCE_SHM=1) and disabling Ryn hardware acceleration each independently remove roughly 95-97% of the anonymous slope, and combining them adds little material benefit. The recurring work therefore lives in the accelerated WebKitGTK DMA-BUF rendering/import/texture path inside the Linux host integration — not in managed retention, optional application integration, WebKit child-process heaps, or explicit-sync behavior (disabling NVIDIA explicit sync alone leaves the slope unchanged). This confirms the reading of the visible-versus-occluded evidence: the growth is an artifact of active accelerated composition, not a steady background allocator.

[Yupmoh]

Hi Uni, thank you for running the comparison tests. The results isolate the problem much more clearly.

Your measurements show:

• Default accelerated rendering: approximately 64 MiB/min
• WEBKIT_DMABUF_RENDERER_FORCE_SHM=1: approximately 3 MiB/min
• HardwareAcceleration = false: approximately 2.2 MiB/min
• Disabling NVIDIA explicit synchronization: no meaningful improvement

This strongly indicates that the memory growth is in WebKitGTK’s accelerated DMA-BUF presentation path on your NVIDIA, Wayland, and GTK4 configuration. It does not appear to come from Ryn’s managed code, IPC, Vue, or application-level object retention.

I also checked whether updating Ryn’s Saucer dependency would address it. Ryn currently uses Saucer 8.0.4, but Saucer 8.0.5 and the current development branch do not contain a relevant Linux DMA-BUF or texture-lifetime fix. Saucer uses the system WebKitGTK installation on Linux, so your test is already running against WebKitGTK 2.52.6, the latest stable release.

For now, the recommended workaround is:

WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 ./PrimalLauncher

I do not recommend WEBKIT_DISABLE_DMABUF_RENDERER=1, because some current WebKitGTK configurations can fail instead of selecting a valid fallback transport.

WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 does not disable all GPU acceleration. It changes how completed frames are transferred from WebKitGTK to the GTK host window. The normal DMA-BUF route can avoid copies and should remain faster when it works correctly. The shared-memory route is a compatibility fallback for systems where the DMA-BUF path is unstable.

Your measurements show that shared memory removes almost all of the runaway growth while using less CPU than disabling hardware acceleration entirely.

I am going to add an explicit Ryn option for selecting this shared-memory presentation mode on Linux, so affected applications will not need to depend on an externally configured environment variable. The normal accelerated route will remain the default because this problem is currently confirmed only on a specific NVIDIA, Wayland, GTK4, and WebKitGTK combination.

I will keep this issue open while I implement and release that option. The underlying buffer-lifetime fix belongs in WebKitGTK, but Ryn can provide a supported and documented compatibility path in the meantime.

Thank you again for the detailed measurements. They provided the evidence needed to distinguish this from an application-level or Ryn-managed memory leak.

[Yupmoh]

The supported Linux rendering workaround is now available in Ryn 0.33.0.

RynOptions.LinuxRenderingMode provides three modes:

• Auto: keeps WebKitGTK's default rendering path
• DmaBuf: explicitly selects the normal DMA-BUF path
• SharedMemory: configures the tested WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 compatibility path before GTK initializes

For the affected NVIDIA and Wayland setup:

builder.ConfigureOptions(options =>
{
    options.LinuxRenderingMode = LinuxRenderingMode.SharedMemory;
});

Auto remains the default because the runaway growth is currently confirmed for a specific NVIDIA, Wayland, GTK4, and WebKitGTK combination. The underlying DMA-BUF lifetime defect remains upstream, but affected Ryn applications no longer need an externally configured environment variable.

Release: https://github.com/Yupmoh/Ryn/releases/tag/v0.33.0
NuGet: https://www.nuget.org/packages/Ryn/0.33.0

[Yupmoh]

Uni's follow-up measurement showed that Ryn 0.35.0's LinuxRenderingMode.SharedMemory was not activating early enough on the affected setup: the in-process option still grew at approximately 60.9 MiB/min, while inheriting WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 at process launch reduced growth to approximately 3 MiB/min.

Ryn 0.35.1 moves the process-wide Linux rendering configuration from RunAsync() to Build(), immediately after the final options have been resolved and before plugin initialization or any Ryn GTK/WebKit native initialization. The environment variable and value are unchanged.

Please retest 0.35.1 with only:

builder.ConfigureOptions(options =>
{
    options.LinuxRenderingMode = LinuxRenderingMode.SharedMemory;
});

Do not set WEBKIT_DMABUF_RENDERER_FORCE_SHM externally for this run, so the result tests Ryn's option directly. If the slope remains unmitigated, that confirms the environment must be inherited at process creation on this platform and Ryn will need a bootstrap/re-exec solution rather than another in-process timing adjustment.

Release: https://github.com/Yupmoh/Ryn/releases/tag/v0.35.1
NuGet: https://www.nuget.org/packages/Ryn/0.35.1

[Yupmoh]

Ryn 0.35.1 was retested without an externally supplied environment variable. LinuxRenderingMode.SharedMemory still grew by 177.15 MiB over 180 seconds (approximately 59.05 MiB/min), effectively unchanged from 0.35.0 and the default DMA-BUF path. This confirms that setting the variable anywhere in managed startup is too late on the affected system.

I explored automatic process replacement, but rejected it as an implicit framework behavior: Build() must not unexpectedly restart the host application, replay user startup code, or complicate debugger, launcher, single-instance, service-manager, and parent-process semantics. The unreleased implementation was reverted, its release workflow was cancelled, and no 0.35.2 package was published.

For this environment, the reliable workaround remains supplying WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 before process creation. Applications may do that through their launcher, desktop entry, launch profile, service configuration, or an application-owned bootstrap/re-execution flow where the application author controls startup side effects. Ryn should document this limitation rather than hide a process restart behind Build().

[Yupmoh]

Correction after clarifying the test configuration: this 30-minute run used Ryn 0.35.1 with LinuxRenderingMode.SharedMemory, without an externally supplied WEBKIT_DMABUF_RENDERER_FORCE_SHM variable. Therefore the result is evidence that Ryn's managed option is taking effect, not evidence for the external process-creation workaround.

Results:

• RSS increased approximately 44.9 MiB over 30 minutes (about 1.50 MiB/min across the full run).
• Growth was front-loaded during startup. From 10 to 30 minutes it increased approximately 11.1 MiB (about 0.55 MiB/min).
• RSS decreased between samples and remained roughly bounded around 370–383 MiB during the final ten minutes.
• The launcher remained responsive and exited normally without rendering errors.

This changes the interpretation of the earlier three-minute 0.35.1 result. Its approximately 59 MiB/min slope measured the initial allocation ramp and was too short to distinguish startup warming from sustained leakage. A completely flat RSS is not expected; reclamation and a bounded fluctuating working set are the important signals.

The remaining comparison needed for certainty is an otherwise identical 30-minute run with LinuxRenderingMode.Auto. If Auto continues climbing while SharedMemory plateaus, that confirms the option end-to-end. CPU remains high at approximately 46–49% and should be investigated separately.