GNOME Bugzilla – Bug 555365
Song changes leak memory
Last modified: 2020-03-17 08:23:23 UTC
I noticed that the banshee process grows a lot when changing songs a lot. As a test I did this: 1) start banshee, write down memory usage 2) hit forward 25 times, write down memory 3) repeat 2 a number of times After 4 times (100 song changes), memory usage was up to ~85 MB, up from ~35 MB. The increase seems to be quite linear, with about +0.5MB on every song change. I assume there is something going wrong here.
Created attachment 120098 [details] Test mem usage after 0, 25, 50, 75 and 100 skips For more information, see this screenshot(s)
Created attachment 120211 [details] heapshot files
This one should be knocked out! Thanks!
Created attachment 120221 [details] heapshot files, round 2 I still see the leak with trunk. For the specific case of rubbing a window over the play header, it does not seem to leak a lot anymore, however, I still see a 40->100 MB increase when skipping about 200 times in a row.
Reopening... as there seems to be something wrong, still.
I can still reproduce it.
Michael, how much does it increase for just one or a few song changes?
(In reply to comment #7) > Michael, how much does it increase for just one or a few song changes? Maybe +0.2 to +0.3 per song change for me using my test database (which only has one album). It's not that much on it's own but it adds up quickly.
I am seeing this too on 1.5. Seems to be a couple megs per 5-10 song changes.
The patch from bug 586498 mostly fixes it. I measured how memory consumption increases after 25, 50, 75 and 100 skips. Git master: 25: +19.9 MiB 50: +16.1 MiB 75: +15.9 MiB 100: +15.2 MiB With the patch: 25: +12.8 MiB 50: +2.2 MiB 75: +1.4 MiB 100: +1.3 MiB
I am seeing similar results as Alexander with the patch though perhaps a bit more, something like 1-2MB per 10-15 tracks. It seems to be a little better.
(In reply to comment #11) > I am seeing similar results as Alexander with the patch though perhaps a bit > more, something like 1-2MB per 10-15 tracks. It seems to be a little better. > Confirming, on a bigger library (2,000 tracks vs 130 tracks) I see these numbers with the patch: 25: +14.1 MiB 50: +3.1 MiB 75: +2.9 MiB 100: +2.3 MiB
Strange that it leaks more with a bigger library. I sorted my library by shortest song first and left it playing over night. The end result was about 8 hours of play and 400 songs, for a total of about 30MB increased memory. The first to play always increased memory by about 12MB even if the song is only 20KB. Maybe that is normal stuff being loaded into memory. The memory usage definitely isn't linear so it doesn't seem as much like a leak if there is much of one any more. Doing the same test again, the memory usage grows 25MB with the first 25 songs which is about what I remember seeing last night, so it only crept up 5MB or so to play the rest of the 400. Some of this memory usage is probably temporary stuff that is garbage collected at some point. Still kind of sad to see memory usage jump up 30MB to play a few songs. Banshee should be lean and mean :)
The patch from bug 586498 is committed. I did another test with this command: $ for i in {1..10000}; do sleep 1; echo $i; banshee-1 --next; done The leak is still there, memory usage after X skips: 0: 53 MiB 360: 83 MiB 1,400: 108 MiB 2,000: 136 MiB 2,500: 155 MiB 3,000: 177 MiB 3,500: 204 MiB
*** Bug 591550 has been marked as a duplicate of this bug. ***
Using banshee 1.5.0 from ppa.. i can confirm the same odd behaviour.. Hope it will be fixed before banshee lands in ubuntu karmic.
Okay, so far I have the following info: The only enabled plugins are * Audio CD Support * Cover Art Fetching * last.fm Radio and Scrobbling * Multimedia Keys * Notificaation Area Icon * Play Queue The queue was set up to fetch tracks randomly from one playlist of 620 tracks by ratings. My 3.5 GB RAM was used up in approx 8 hours of ambient music: one track per 7 mins on average, I did not skip any tracks today. I used top to see memory usage after my PC became slow. The process banshee-1 had 2494m of VIRT, and 1.7g in RES, and - what was remarkable too - process notify-osd had 1027m and 531m in RES. These values did not decrease for notify-osd after I issued kill -TERM for the banshee-1. So - it may be that this issue is not contained within banshee itself, and may require periodic reboots and not only banshee restarts. I guess I would try plugging off that Notification Area Icon and checking what the stats would be. Also: as this ticket seems to be more alive than #586052 - I post this info here. But this has little to do with often song changes, as I did not touch that function for this session at all.
Oh, and... anton@arcano:/$ banshee --version Banshee 1.6 Beta 2 (1.5.1) http://banshee-project.org Copyright 2005-2009 Novell, Inc. and Contributors. anton@arcano:/$ uname -a Linux arcano 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux
"Song changes" include the user manually pressing next, but also the playback controller seeing one song ended and setting up the next one. They are largely equivalent in terms of the code that makes them happen.
Memory usage grows even when hiding/revealing Banshee via the notification applet icon in gnome. I've noticed that with each hide/reveal Banshee swallows 0.1MB of RAM.
Created attachment 148229 [details] [review] Call Dispose() on ImageSurface before overwriting This is a tentative patch to try to fix what I think might be a leak when the cover art image displayed changes. I've noticed a slight improvement with this patch : +5MB after 100 skips instead of +6MB (while running "mono Nereid.exe", no debug).
Review of attachment 148229 [details] [review]: I haven't looked at this closely, but doesn't TrackInfoDisplay use the ArtworkManager, which has a cache of surfaces it doesn't dispose unless it needs to?
I can confirm this bug. After about 20 hours playing music Banshee allocated 1,5 GB of RAM... For me memory leak is not linear, it's usually 0,5 - 2,0 MB when Banshee switch to next song. I use Ubuntu 9.10 (with all updates) and Banshee 1.6 Beta 2 (1.5.1).
Unfortunately this problem still persists in banshee 1.6 beta 4 (1.5.3). Every song change will increase the amount of memory Banshee uses.
Yeah, we have to fix this before 1.6 - this bug is bad.
Am testing this now, thought I'd share my script. It measures RSS which isn't great I guess, but should do: for i in {1..10000}; do sleep 1; echo "$i: $(perl -e 'print @ARGV[0]/1024.0;' $(ps h -o rss $(pidof banshee-1)))"; banshee-1 --next; done
Responding to my comment #22, we use the ArtworkManager there, but we call LookupScaleSurface (string id, int size) which doesn't use the cache - so we should be disposing it, probably. I'm going to apply/test the patch, will report back.
Without Bertrand's patch: 10: 94.6 100: 103.7 200: 104.6 300: 108.6 394: 114.7 With it: 10: 95.7 100: 102.8 200: 105.5 300: 105.6 394: 107.5 So it does seem to improve things.
Created attachment 153123 [details] Graph of memory usage vs. song changes I just tracked banshee memory usage listening to my local library and also using the last.fm plugin. It appears that the memory usage increases much more rapidly when listening to last.fm (see attached graph), so there might be an additional leak there. Not sure what caused the sudden shift in memory usage at around 150 song changes, banshee played minimized to tray for the whole duration.
I'm seeing almost no difference with Bertrand's patch: 50: 75 MiB 500: 104 MiB 1000: 130 MiB 1500: 155 MiB 2000: 178 MiB With the patch: 50: 73 MiB 500: 103 MiB 1000: 128 MiB 1500: 154 MiB 2000: 179 MiB
Given that I reported the bug initially, I made some new test runs myself 1) 1 sec skips and window minimized 50: 58.7734375 100: 59.13671875 500: 63.95703125 1000: 72.08203125 2000: 76.2734375 => looks quite good to me 2) 1 sec skips and window shown 50: 59.375 100: 59.33203125 500: 66.2890625 1000: 73.1171875 2000: 78.3359375 3000: 81.36328125 4000: 85.94140625 => about the same, within tolerance 3) 5sec skips 50: 64.4453125 100: 66.69140625 500: 67.453125 1000: 76.12890625 2000: 80.015625 => about the same, within tolerance 4) 60 sec skips 1: 60 50: 65.84765625 100: 70.6953125 200: 71.89453125 300: 72.81640625 400: 72.2734375 500: 72.7109375 517: 72.6640625 518: 79.234375 600: 80.79296875 So, this is still not "perfect" but I am really surprised to never see Banshee take more than 80 mb, even after running all night long in a semi-realistic way (playing a minute of each song) while Gabriel and Alexander both see > 100 mb usage. I am using banshee 1.5.3 on Fedora 12. The last.fm plugin is disabled... maybe it causes the leak, even when "just" reporting plays count? Also it would be interesting to know where the 72mb->79mb jump came from (see 517->518 in series 4 above)
With lastfm reporting on, numbers are slightly higher but still quite low compared to before... 10: 69.4609375 100: 73.34375 500: 73.82421875 1000: 81.65234375 2000: 86.16015625 3000: 91.40625 4000: 93.14453125
Created attachment 153223 [details] Few more traces of memory usage I prepared a few other profiles using my local library with the last.fm plugin disabled. Typically, the memory usage increases slowly, until something is triggered that makes the memory usage grow much faster. I'm not sure what it could be since it was just playing in the background minimized to the notification area while I was away from the computer. Perhaps it could be a certain music file type that triggers this (I have a variety of mp3, ogg and m4a files)? Since the rapid memory increase also happens with the last.fm plugin disabled, the increased usage I noticed in my last post may just have been a coincidence. Is there a debug feature in banshee that allows logging of each file that is played upon a song change?
You can use banshee-1 --query-uri to get the playing URI out. So modifying the above for loop: for i in {1..10000}; do sleep 1; echo "$i: $(perl -e 'print @ARGV[0]/1024.0;' $(ps h -o rss $(pidof banshee-1))) $(banshee-1 --query-uri)"; banshee-1 --next; done
As for the "jump" in memory usage I mentioned in comment 31, I created a smart playlist to see what song number 518 and 517 where. They where both from the same album, so, no new file type or album art or anything: strange. For reference, the plugins I have activated are: audiocd, fsqueue, inetradio, playqueue, podcast, msdap, coverart (lastfm reporting and notification plugin tested as well, they don't make a big difference) Maybe Alexander could try again with this set and see if he still gets memory usage up to ~180mb
(In reply to comment #35) > For reference, the plugins I have activated are: audiocd, fsqueue, inetradio, > playqueue, podcast, msdap, coverart (lastfm reporting and notification plugin > tested as well, they don't make a big difference) > > Maybe Alexander could try again with this set and see if he still gets memory > usage up to ~180mb I tested again with ALL extensions disabled. I also use the shuffle by song mode, the leak is more noticeable this way. 50: 74 MiB 500: 98 MiB 1000: 119 MiB 1500: 134 MiB 2000: 154 MiB Much better than with extensions but there's still a leak.
I tested with shuffle as well now, can't say I see any difference: 10: 64.87 50: 73.22 100: 74.14 500: 75.81 1000: 76.84 2000: 80.31 3000: 82.93 4000: 87.75
Created attachment 153302 [details] memory usage during normal playback After a few more tests it doesn't appear that the increase in memory is related to any particular file type. I have added two final traces of memory usage during normal playback of a local library or last.fm (by polling memory usage every 20 sec). Memory usage increases much more rapidly when listening to last.fm compared to a local library. In contrast to playing from a local library, there is no drop in memory usage after a song change with the last.fm plugin, so perhaps buffered content isn't cleared properly between songs in the latter case?
I thought I'd test totem to see if maybe it was a GStreamer problem. Doesn't seem to be though: 10: 58.453125 2000: 62.984375
(In reply to comment #22) > Review of attachment 148229 [details] [review]: > > I haven't looked at this closely, but doesn't TrackInfoDisplay use the > ArtworkManager, which has a cache of surfaces it doesn't dispose unless it > needs to? TID doesn't pass the useCache parameter when calling the ArtworkManager. I committed Bertrand's patch as it does slightly improve things.
I fixed a few memleaks in git master, together they reduce the increase in memory usage in half in my tests: 50: 70 MiB 500: 80 MiB 1000: 90 MiB 1500: 98 MiB 2000: 103 MiB (In reply to comment #37) > I tested with shuffle as well now, can't say I see any difference: > > 10: 64.87 > 50: 73.22 > 100: 74.14 > 500: 75.81 > 1000: 76.84 > 2000: 80.31 > 3000: 82.93 > 4000: 87.75 Michael, which versions of gtk2 and pango you have installed? Also, do you have many playlists? How big are they compared to the library?
(In reply to comment #41) > I fixed a few memleaks in git master, together they reduce the increase in > memory usage in half in my tests: Nice! > Michael, which versions of gtk2 and pango you have installed? Also, do you have > many playlists? How big are they compared to the library? gtk2-2.18.6-3.fc12.i686 pango-1.26.2-1.fc12.i686 gtk-sharp2-2.12.9-1.fc12.i686 My main music library has 14250 songs (the .db file is 11.2 MB) - Playlists: 20s, 94s, 0s, 3s - Smart playlists: 5s, 15s, 30s, 1338s So I guess I am not a heavy playlist user. Do you think having more playlists would make the memory usage increase faster for me? If so, what kind of playlist, how many lists and how many items per list should I try?
OK, I spent this entire weekend looking at the issue, made some progress but kind of stuck and could use a hand. Here is what I found out: When track changes, all playlists intercept the event and either reload or invalidate their caches. This in turn reloads the underlying model and triggers its Reloaded event. Now, I noticed that commenting out this method in BansheeListModel.cs: protected override void OnReloaded () { ThreadAssist.ProxyToMain (base.OnReloaded); } ... (which just results in the base method called in the same thread) significantly reduces leak. Instead of 10 MiB increases in memory usage per 500 track changes, I'm seeing 3-4 MiB increases when the method is commented out. Behind the scenes, ProxyToMain() wraps its parameter into a couple of anonymous delegates and calls GLib.Idle.Add() [0]. Replacing ProxyToMain() with GLib.Idle.Add() directly in OnReloaded() doesn't reduce the memory usage. On the other hand, GLib.Idle.Add() doesn't leak: IdleProxies [1] get disposed and Source.source_handlers.Count [2] doesn't increase. I also created an empty project that just calls GLib.Idle.Add() repeatedly in a new thread, and it doesn't leak. This means that the leak is caused either by the way Banshee interacts with GLib.Idle or by some mysterious bug in the Mono runtime. If you have any other ideas - please comment. Until then I'm putting this bug on hold to regain my sanity %) [0] http://git.gnome.org/browse/banshee/tree/src/Core/Banshee.ThickClient/Banshee.Gui/GtkBaseClient.cs#n263 [1] http://anonsvn.mono-project.com/viewvc/trunk/gtk-sharp/glib/Idle.cs [2] http://anonsvn.mono-project.com/viewvc/trunk/gtk-sharp/glib/Source.cs
I just activated "Disable features requiring Internet access" to stop banshee from fetching cover arts and deleted my cover-cache. After a couple of songs played, memory is still below 100MB. (before: it raised without any limit...)
This bug can be duplicated simply by doing this (Ubuntu 10.04 - i will include my sample numbers - i have ~19000 songs): 1. Start System Monitor note banshee-1 is using 38.6 MB 2. Scroll the list of songs to the bottom (using the slider). 3. banshee-1 is using 38.6 MB 4. Scroll the list of songs to the top (using the slider). 5. banshee-1 is using 43.0 MB 6. Repeat Step 2. 7. banshee-1 is using 46.2 MB 8. Repeat Step 4. 9. banshee-1 is using 47.2 MB I got the number in Step 2 wrong - point is - do not click play and scroll the list of songs and you see banshee eat up memory. Another example: 1. start banshee 2. click Playback > Shuffle > Shuffle by Song 3. click the Music node of the tree at the left. 4. click Play. 5. click Now Playing 6. press N to scroll 7. Repeat 6. Memory usage stays relatively steady. memory fluctuates 1-3 MB Memory does not get eaten up unless the list of songs is focused (you can see the green play icon beside the song). There ar hit an miss ways to have the list of songs visible and scroll songs without the list actually scrolling.
weirdo12, try scrolling the song list really slow, e.g. by just pressing the [V] button at the bottom. Yes this takes a loooong time (lock the mouse button or something). At least this used to increase memory usage really quick.
*** Bug 634899 has been marked as a duplicate of this bug. ***
I noticed this bug while reporting bug 647478 and bug 647480. In short, with those bugs I had only 1 file in the library, and all plugins disabled except for "Play Queue". The MP3 file is 0.1 seconds and when played on a loop, Banshee leaks approx 8mb per second. Note that the MP3 plays less than 10 times per second due the extremely high CPU use on song change, so the actual leak was more than 0.8mb per song change.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.