Bug 189868 - Memory leak with collection watching
Summary: Memory leak with collection watching
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Local (show other bugs)
Version: 2.1-SVN
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-17 13:05 UTC by Thorsten Mühlfelder
Modified: 2009-05-03 00:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Mühlfelder 2009-04-17 13:05:53 UTC
Version:           svn revision 953597 (using KDE 4.2.2)
Compiler:          GCC 4.3.3 
OS:                Linux
Installed from:    Unlisted Binary Package

At startup Amarok 2.1svn (at the moment revision 953083) takes about 80 MB of RAM, which I think is OK for my big music collection (~40.000 tracks). But then Amarok constantly increases memory usage by about 0.5-1 MB every minute. Even if it does nothing (not playing, not scanning, ...).
With this behaviour Amarok completely slows down my computer after running for a day, because every other application has to swap.

To solve the problem I had to disable "Watch Folders For Changes". Then the memory usage usually is below 150 MB.

My collection is on a ext3 partition and mainly consists of mp3 and Ogg Vorbis. There are some musepack and aac files, too.

See also the forum discussion: http://amarok.kde.org/forum/index.php/topic,16825.0.html
And I guess bug 189850 is related to this, too.
Comment 1 Mark Kretschmann 2009-04-17 13:14:51 UTC
Thanks for the report. We've already started to run some Valgrind checks, and I've identified a possible leak in Solid or Amarok (not sure).


I've created the following bug report for Solid, let's see what they say:

BUG 189863
Comment 2 Andreas Hartmetz 2009-05-03 00:54:27 UTC
This bug came up on #amarok today and it's already fixed in revision 961137.
Unrelated to the Solid problem; that one also looks valid to me though.