I am experiencing a significant memory leak in the BeefWeb plugin when managing a large playlist (approx. 11,000 tracks) on a headless Linux system. The deadbeef-main process grows by ~1.5MB to 2.5MB every time a track is skipped or the "next" command is issued. In my environment, this eventually leads to the Linux OOM killer terminating the process once it hits approximately 7.2GB RSS.
Environment:
OS: Linux (Ubuntu 24.04 / Mint 22.x)
Kernel: 6.x
DeaDBeeF Version: 1.10.1
BeefWeb Plugin Version: Feb 2025 build (approx. 2.7MB .so file)
Hardware: HP Elite 8300 SFF (8GB RAM) headless
Steps to Reproduce:
Load a playlist with a large number of tracks (11,000 in my case).
Ensure the BeefWeb plugin is active.
Monitor the process memory usage: ps -o rss -p $(pgrep deadbeef).
Issue several "next" commands via CLI: deadbeef --next.
Observe that the RSS increases by 1-2MB per skip and does not plateau.
Additional Context:
I have verified that this behavior is specific to the plugin. When the beefweb.so plugin is disabled/removed, skipping tracks in the same 11k-track playlist results in a stable RSS (~94MB to ~96MB) that does not continue to grow linearly. It appears the leak may be related to playlist serialization or metadata buffering triggered by track-change events and may not be limited to large playlists, even as this playlist size may have helped to reveal the memory leak.
I am experiencing a significant memory leak in the BeefWeb plugin when managing a large playlist (approx. 11,000 tracks) on a headless Linux system. The deadbeef-main process grows by ~1.5MB to 2.5MB every time a track is skipped or the "next" command is issued. In my environment, this eventually leads to the Linux OOM killer terminating the process once it hits approximately 7.2GB RSS.
Environment:
OS: Linux (Ubuntu 24.04 / Mint 22.x)
Kernel: 6.x
DeaDBeeF Version: 1.10.1
BeefWeb Plugin Version: Feb 2025 build (approx. 2.7MB .so file)
Hardware: HP Elite 8300 SFF (8GB RAM) headless
Steps to Reproduce:
Load a playlist with a large number of tracks (11,000 in my case).
Ensure the BeefWeb plugin is active.
Monitor the process memory usage: ps -o rss -p $(pgrep deadbeef).
Issue several "next" commands via CLI: deadbeef --next.
Observe that the RSS increases by 1-2MB per skip and does not plateau.
Additional Context:
I have verified that this behavior is specific to the plugin. When the beefweb.so plugin is disabled/removed, skipping tracks in the same 11k-track playlist results in a stable RSS (~94MB to ~96MB) that does not continue to grow linearly. It appears the leak may be related to playlist serialization or metadata buffering triggered by track-change events and may not be limited to large playlists, even as this playlist size may have helped to reveal the memory leak.