Suggestion: Limit size of diagnostic logs to prevent memory usage growing indefinitely
34 views
Skip to first unread message
avrdude
Jul 12, 2026, 1:19:21 PM (2 days ago) Jul 12
to Soulseek Technical Discussion
Hello SoulSeek team!
As you probably already are aware of, the SoulSeekQt client leaks a lot of memory. In my case, about 1 GB per day (grew to 11.8 GiB after 12 days, before becoming unresposive).
Today I decided I'd finally had enough and decided to take things into my own hands. By inspecting the contents of allocated memory regions it quickly became evident that the diagnostic logs were the primary culprit. Now obviously disabling diagnostics would fix this problem (as has been suggested before), but I prefer keeping them enabled as I find them quite useful.
The logging buffer (or any data buffer for that matter) should never be allowed to grow indefinitely. My suggestion is to enforce a (configureable) maximum size after which old messages start getting dropped.
Or even better: use a fixed-size ring buffer; now you only need to malloc() once at initialisation (deterministic :D)!
----
avrdude done. Thank you.
As you probably already are aware of, the SoulSeekQt client leaks a lot of memory. In my case, about 1 GB per day (grew to 11.8 GiB after 12 days, before becoming unresposive).
Today I decided I'd finally had enough and decided to take things into my own hands. By inspecting the contents of allocated memory regions it quickly became evident that the diagnostic logs were the primary culprit. Now obviously disabling diagnostics would fix this problem (as has been suggested before), but I prefer keeping them enabled as I find them quite useful.
The logging buffer (or any data buffer for that matter) should never be allowed to grow indefinitely. My suggestion is to enforce a (configureable) maximum size after which old messages start getting dropped.
Or even better: use a fixed-size ring buffer; now you only need to malloc() once at initialisation (deterministic :D)!
----
avrdude done. Thank you.
Reply all
Reply to author
Forward
0 new messages