Memory leakage with Spotify Linux Preview 0.9.11.27.g2b1a638c in Ubuntu 12.04 LTS

[psaxl]

Hello,

I am really pleased to use Spotify Linux Preview. The application has been really well designed but suffers from a huge memory leakage. Indeed, I am currently using Ubuntu 12.04 LTS with GNOME 3 Session Fallback (Classic). Hence, when I launch Spotify Linux 0.9.11.27.g2b1a638c. The application is loaded as an Indicator Applet in GNOME with the typical green icon of Spotify. That is, it is loaded into the process indicator-applet-complete.

The process in question usually use 50MB at worse but when Spotify is launched and after a dozen of songs played, indicator-applet-complete now uses 600MB and at the end of the day, the memory used is around 3GB...

Henceforth, killing all process instances of Spotify does not deallocate the memory and indicator-applet-complete keeps the whole allocated memory... I think there is a design problem : (1) a loaded song should be deallocated from meory as soon as it stopped, (2) quitting all Spotify instances should free the memory it had allocated.

Moreover, I do not understand why there are so many instances of the process SpotifyHelper...

Regards,

-Hai Nguyen Van

[olejon · Accepted solution]

Hmm, I have not noticed this. Anyway, a completely new Spotify is on its way so we'll see then. Wouldn't expect any fixes to 0.9.x.

All the Helper processes are because Spotify uses Chromium Embedded to show much of the content (most of it), basically a web browser inside the Spotify application. Chromium, which Google Chrome is based on, uses multiple processes. Old-school users immediately think this is bad, but it's not. It's a way to separate work going on, so that for example the UI is not blocked when work is going on. If you had tried the version before the multiple processes Chromium was used in Spotify, you would have noticed that the UI would lock up a lot more when browsing around and scrolling would be laggy and completely freeze. Also, if a Helper process crashes, it doesn't take down the entire application. Just like a tab in Chrome can crash without crashing Chrome itself.

Now, Chrome is known to be a memory hog, but mostly people today have plenty of RAM, and it's simply making use of it. But I think work is being done to optimize Chromium now that it's used on Android (it was pretty slow and laggy in the beginning, much better now), and low powered Chromebooks.

Basically, don't care about the number of processes. As a developer it is good practice to put background work in another outside of the main UI thread. This makes use of all the cores CPUs have today. For example I do some Android development, and a lot of stuff you are not even allowed to do in the UI thread anymore. It must be put in an AsyncTask.

You should only care if it slows down your system/affect other apps. Now if all apps start to take this approach, embedding Chromium or WebKit or whatever in their apps, it could start to become a problem on systems with little RAM. I would not choose less than 8 GB today.

The memory problem you see is not good, but hang in there until 1.0 is released for Linux, and we'll see. The bug you see could be a bug in the indicator project, not in Spotify. Have you tried in Ubuntu 14.04 for example? The GNOME version in 12.04 is not the best. GNOME 3 has improved a lot since 12.04.

[psaxl]

Thanks for your reply. I now understand why there are some many process instances of SpotifyHelper...

Concerning the memory leakage with indicator-applet-complete and as you suggested, I installed and made tests of Spotify Linux on a Ubuntu 14.04 virtual machine and no problem occurs. So it is possible that the problem is only related to Ubuntu 12.04 LTS. I have just reported this bug on Lauchpad as bug #1407069.

I agree that Ubuntu 12.04 version is getting old but I still have several proprietary software that can only run on that version (due to old version of librairies I guess). Hence, I cannot afford upgrading OS version for now and I don't really know if gnome-session-fallback is still maintained or not...

Regards,