Renderer memory grows continuously to 11+ GiB on Apple Music New page (Linux)

[uyu74]

Steps to Reproduce

1. Launch Sidra 0.4.1 AppImage on Arch Linux
2. Let it load the default Apple Music "New" page: https://music.apple.com/us/new?l=zh-Hans-CN
3. Leave the window open without deliberate interaction
4. Observe Sidra's renderer process in btop

Expected Behavior

Sidra should keep a stable, reasonable memory footprint while displaying the Apple Music New page.

Actual Behavior

After launch:

• Around 3 minute after the renderer started: Renderer RSS: ~7.34 GiB, CPU: ~157%
• Memory composition:
  • ~7.2 GiB private anonymous memory
  • This is not explained by disk cache; ~/.config/Sidra was ~561 MiB total.
• Approximate growth rate: ~53 MiB/s during sampling.
• Later observation: renderer reached ~11.42 GiB RSS and ~158% CPU.

Error Output

No application error was shown. No related error was written to Sidra's main log, no Crashpad dump was produced, and no kernel OOM event occurred.

Version

Sidra 0.4.1 (AppImage)

Environment

• OS: Arch Linux
• Kernel: 7.0.11-1-cachyos-bore
• Session: Wayland
• Desktop/compositor: niri
• GPU: Intel Arc Pro 130T/140T
• Graphics driver: i915
• Total RAM: 30 GiB
• Swap: 79 GiB
• Sidra language: zh-Hans-CN
• Apple Music storefront: us

Additional Context

Sidra's ~/.config/Sidra/logs/main.log confirms that the affected session loaded Apple Music's New page:

[2026-08-25 23:56:48.330] [info] (main) loading Apple Music...
[2026-08-25 23:56:52.061] [info] (main) page loaded: https://music.apple.com/us/new?l=zh-Hans-CN

This log excerpt is from a normal launch and only confirms the affected page; the runaway renderer did not emit an
application-level error.

Checklist

• I have searched existing issues to avoid duplicates
• I have provided all the requested information above
• I can reproduce this issue consistently

[MariusQuabeck]

I collected two 10-minute measurements with Sidra 0.4.1 from the official amd64 Deb package on Ubuntu 26.04 LTS, GNOME 50.1, Wayland, kernel 7.0.0-29, Intel Haswell/i915, German storefront. This system did not reproduce the reported 53 MiB/s idle runaway.

Controlled idle run: fresh launch on https://music.apple.com/de/new, authorised session, no playback, navigation or input; 21 samples at roughly 30-second intervals. I recorded the systemd cgroup's memory.current, summed PSS from each process's smaps_rollup, and summed RSS.

metric	t=0	t=120 s	t=602 s	change from 120 to 602 s
cgroup memory.current	656184 KiB	390528 KiB	390996 KiB	+468 KiB
summed PSS	596432 KiB	451733 KiB	450589 KiB	-1144 KiB
summed RSS	1044860 KiB	901080 KiB	900220 KiB	-860 KiB
renderer RSS	381572 KiB	247296 KiB	246440 KiB	-856 KiB

After the first two minutes of loading/cleanup, the cgroup stayed around 381 MiB and was effectively stable for the remaining eight minutes.

Interactive run: 601 seconds with playback, track changes, navigation, MPRIS commands, theme/system-style changes and an automatically loaded 1080p H.264 teaser. Summed RSS went from 849524 to 1342844 KiB (+493320 KiB); renderer RSS went from 427236 to 898504 KiB (+471268 KiB).

The interactive result is suggestive, but it is not by itself proof of a leak: the workload mixed several actions and summed RSS double-counts shared pages. In combination with the stable idle control, it may point to a workload-, media- or page-state-dependent path rather than unconditional growth on every New page. I can provide the complete 21-row TSV samples if useful.

[flexiondotorg]

Please sign in to GitHub and download sidra-linux from this successful current main build, which includes #221 and expires on 10 September 2026. Extract sidra-linux.zip, run chmod +x Sidra-linux-x86_64.AppImage && ./Sidra-linux-x86_64.AppImage, and compare it with official 0.4.1 on the same machine at https://music.apple.com/us/new?l=zh-Hans-CN. Stop each run before memory pressure, then report whether continuous growth returns, with the elapsed time and renderer RSS at the start and stop.