Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

VRAM leak: orphaned DMA-BUFs sized to physical monitor accumulate while streaming a virtual headless output (wlr capture, NVENC)

Open
  • Is something wrong?
#5,810 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, linux
Domain
computer-graphics, performance

Research direction

Start by tracing Sunshine's wlr capture entry point and its zwlr_screencopy_manager_v1 DMA-BUF lifecycle while reproducing the headless-output case with the measurements described. Compare allocation and release behavior during streaming, disconnect, and Sunshine restart; done means unattributed VRAM and orphaned DMA-BUF counts remain flat and return to baseline after disconnect.

Written by the indexing model from the issue text.

Description

Describe the Bug

Streaming from a virtual headless output leaks VRAM as orphaned DMA-BUFs that
are visible in neither nvidia-smi's process list nor any process's fd table.
The leak accumulates continuously (~1.3 GB/h) while a stream is active, and
survives client disconnect — only restarting Sunshine frees it.

Measured on an RTX 5090 32GB over two sessions:

  • ~30 GB VRAM unaccounted for after ~2 days of intermittent streaming
  • 24.9 GB leaked after one overnight session; freed instantly by
    systemctl --user restart sunshine (24893 → 2723 MiB)
  • 1-hour instrumented run: unattributed VRAM grows 1819 → 2570 MiB while
    streaming, stays flat after client disconnect, grows again on reconnect

Key observation: leaked buffers match the physical monitor, not the streamed one

/sys/kernel/debug/dma_buf/bufinfo (as root) shows thousands of leaked
buffers with refcount 2 and no attached devices:

size       flags      mode       count    exp_name  ino       name
39321600   00000002   02080007   00000002 drm       00974892  <none>
  Attached Devices:
  Total 0 devices attached
... (repeated ~800x, plus a second size class)
20971520   00000002   02080007   00000002 drm       00974746  <none>
  • 39321600 bytes = exactly 3840×2560×4 → the physical monitor (BenQ RD280U)
  • 20971520 bytes = 2048×2560×4 (aligned variant)
  • The streamed output is a virtual headless monitor "SUNSHINE" at 1512×982
    (output_name = SUNSHINE), i.e. the leaked buffers are the wrong size for
    the capture target — they appear to be allocated per capture cycle against
    the physical display and never released.

Config

capture = wlr
output_name = SUNSHINE

Hyprland (Wayland). Sunshine uses the zwlr_screencopy_manager_v1 path
("Screencasting with Wayland's protocol" in the log), NVENC encoder.

Environment

  • Sunshine 2026.914.233613, commit 63d35f702ee9e362e43263742981836ec0710384
    (includes #4757, #4588, #5023 — behavior persists)
  • Arch Linux, Hyprland (wlroots screencopy), NVIDIA RTX 5090
  • Driver: nvidia-open-dkms 610.57.04
  • Note: nvidia-open 610.x exposes no /sys/kernel/debug/nvidia client list, so
    the leak is only visible via dma_buf/bufinfo and by diffing
    nvidia-smi --query-gpu=memory.used against the attributed process sum.

Reproduction

  1. Hyprland with one physical 4K monitor + one headless output (e.g.
    hyprctl output create headless SUNSHINE), Sunshine output_name = the
    headless output, capture = wlr
  2. Stream for ~1 hour; periodically measure unattributed VRAM =
    nvidia-smi --query-gpu=memory.used minus the process sum
  3. Disconnect the client — leak does not drop
  4. systemctl --user restart sunshine — leak drops to baseline instantly

Expected behavior

DMA-BUFs used for capture should be released when the frame is consumed; VRAM
usage should stay flat (minus normal encoder buffers) for the session
lifetime and drop on client disconnect.

Dominant language
C++
Stars
41.4k
Forks
2.1k
Avg merge
20h 19m
Merged PRs (30d)
125

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LizardByte/Sunshine

All issues in LizardByte/Sunshine

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.