Juk increases its (heap) memory usage in a slow but never stopping way after switching to next track . Reproducible: Always Steps to Reproduce: 1. start juk, ensure there are enough items in the playlist 2. in konsole/shell, run the following command: while true ; do qdbus org.kde.juk /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next 2> /dev/null sleep 5 done 3. leave the computer, then come back a few hours later and use ksysguard the check the memory usage of juk. Actual Results: It consumes 100+ MB heap memory and keeps growing. Expected Results: It should not increase its memory usage in a infinite way. Juk is built from git master today
Can you run it on massif ? valgrind --tool=massif juk then wait a few hours, close juk, and attach the generated file
Created attachment 81085 [details] valgrind data hope this help.
Created attachment 81112 [details] BZIP2-compressed massif output data I've done some brief attempts to re-create. One thing I would recommend is to cycle through the same small playlist so that the increase in heap usage is known to be due to a *leak* and not just the first allocation for a new track/metadata/strings/etc. This log mostly cycles through an Evanescence playlist from Amazon MP3 (with embedded album art). Though there does seem to be an increasing memory usage profile, it only seems to be coming from gstreamer 0.10. Versions: phonon-gstreamer v4.6.0-90-g385411d phonon/phonon v4.6.0-387-g23795b6 gstreamer GStreamer 0.10.36 I will try again with latest&greatest phonon and pgst just to make sure and see what's going on, but I don't see anything JuK-specific, it might be a dupe of bug 281509
Created attachment 81114 [details] BZIP2-compressed massif output data (Round 2) This is a more data-intensive massif session, which focuses on switching tracks within a single smallish playlist automatically using a DBus command on a timer (along with a small delay to ensure JuK is actually playing the next track before trying to advance in the playlist, due to a different bug in the player which sometimes stops playback if you try to advance too fast). The memory leak is more obvious here, see http://imgur.com/RTimN2m for a screenshot.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.