Bug 142263

Summary:	memory leak in amarok
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Marko Mäkiö <marko.makio>
Component:	KDE	Assignee:	E-mail List <kde-maintainers>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P2 - High	CC:	mrmazda
Version:	Final
Target Milestone:	---
Hardware:	i686
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Marko Mäkiö 2006-01-10 10:52:40 UTC

Amarok eats memory while playing mp3 or ogg files with helix engine. This is probably the same bug as reported here: http://bugs.kde.org/show_bug.cgi?id=116223 

  PID PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17212 15   0  181m 150m  24m S  0.0  7.5   5:01.37 amarokapp
17263 16   0 61104  37m  17m S  0.0  1.9   0:00.00 amarokapp
17264 16   0 61104  37m  17m S  0.0  1.9   0:00.00 amarokapp

5 minutes later:
 PID  PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17212 16   0  188m 158m  24m S  0.0  7.8   5:02.10 amarokapp
17263 16   0 61104  37m  17m S  0.0  1.9   0:00.00 amarokapp
17264 16   0 61104  37m  17m S  0.0  1.9   0:00.00 amarokapp

Comment 1 Felix Miata 2006-01-23 23:20:10 UTC

My RAM size is 512M with 784M swapper. I'm using 10.0 DVD install fully
patched with latest updates, though I didn't install latest kernel until
after I discovered this problem. Amarok AFAIK is set up with nothing but
defaults using the Helix engine. I "copied" most of the oggs from a
samba share with about 60 files in it into a playlist, shuffled, and set them to playing random.

NAICT, as each song starts, another chunk of RAM is used equal to the
song filesize, and it's apparently never given back. Leaving Amarok run long
enough keeps chunking away at swap, which eventually exhausts, hanging
X.

Comment 2 Dirk Mueller 2006-01-24 09:45:57 UTC

can you reproduce it only with ogg? and if you copy the files locally, does it work then?

I'll see if I can reproduce that.

Comment 3 Felix Miata 2006-01-24 14:31:10 UTC

No change from copying locally, and 8 of the 62 files in the playlist are mp3, the rest ogg.

  PID  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13995  147m 118m  22m S  0.0 23.5   0:38.38 amarokapp
14335  143m 114m  22m S  0.0 22.8   0:00.00 amarokapp
13380  107m  69m  23m S  0.0 13.8   3:02.87 seamonkey-bin
13329 68496  31m  18m S  0.0  6.3   0:04.28 firefox-bin
13256 83656  30m  22m S  0.0  6.0   0:03.60 epiphany
14000 47448  23m  17m S  0.0  4.6   0:00.00 amarokapp
14001 47448  23m  17m S  0.0  4.6   0:00.00 amarokapp
13104 50784  22m 3532 S  0.0  4.5   1:27.59 X
13245 30948  17m  13m S  0.0  3.4   0:17.60 kicker
13264 34144  17m  13m S  0.0  3.4   0:00.92 konqueror
13260 29132  16m  12m S  0.0  3.2   0:13.49 ksirc
13250 29572  15m  11m S  0.0  3.0   0:01.53 suseplugger
13252 29568  14m  11m R  0.0  3.0   0:03.45 konsole
13255 27784  14m  11m S  0.0  2.9   0:01.07 kmix
13223 29264  14m  11m S  0.0  2.9   0:01.49 kded
13240 27196  13m  10m S  0.0  2.7   0:06.01 kwin
13253 28076  13m  10m S  0.0  2.7   0:01.11 ksnapshot
13243 27516  12m  10m S  0.0  2.5   0:01.09 kdesktop
14244 25540  12m 9.8m S  0.0  2.5   0:01.12 krandrtray
13273 31844  12m 9.9m S  0.0  2.5   0:00.47 knotify
13248 25528  11m 9.8m S  0.0  2.4   0:00.97 klipper

Comment 4 Felix Miata 2006-01-25 16:06:55 UTC

Switching engine to Xine keeps RAM consumption reasonable:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13380 moz       15   0  116m  79m  23m S  0.0 15.8  14:32.89 seamonkey-bin
16405 moz       15   0 74056  35m  22m S  5.0  7.1   3:00.08 amarokapp
16642 moz       15   0 73928  35m  22m S  0.0  7.1   0:00.00 amarokapp
13329 moz       16   0 68496  31m  18m S  0.0  6.3   0:04.33 firefox-bin
13256 moz       16   0 83656  30m  22m S  0.0  6.0   0:03.65 epiphany
16410 moz       17   0 47868  23m  17m S  0.0  4.7   0:00.00 amarokapp
16411 moz       17   0 47868  23m  17m S  0.0  4.7   0:00.00 amarokapp
13104 root      15   0 51060  22m 3532 S  0.0  4.5   3:29.27 X
13245 moz       15   0 30948  17m  13m S  0.0  3.4   1:49.91 kicker
13264 moz       16   0 34144  17m  13m S  0.0  3.4   0:00.92 konqueror
13260 moz       16   0 29132  16m  12m S  0.0  3.3   0:28.62 ksirc
13252 moz       16   0 29784  15m  11m R  0.0  3.0   0:06.18 konsole
13250 moz       16   0 29572  15m  11m S  0.0  3.0   0:01.53 suseplugger
13255 moz       15   0 27784  14m  11m S  0.0  2.9   0:01.33 kmix
13223 moz       15   0 29264  14m  11m S  0.0  2.9   0:01.76 kded
13240 moz       16   0 27196  13m  10m S  0.0  2.7   0:09.66 kwin
13253 moz       16   0 28076  13m  10m S  0.0  2.7   0:01.12 ksnapshot
13243 moz       16   0 27516  12m  10m S  0.0  2.5   0:01.27 kdesktop
14244 moz       16   0 25540  12m 9.8m S  0.0  2.5   0:01.13 krandrtray
13273 moz       16   0 31844  12m 9.9m S  0.0  2.5   0:00.47 knotify
13248 moz       15   0 25528  11m 9.8m S  0.0  2.4   0:01.10 klipper

Comment 5 Dirk Mueller 2006-01-25 16:13:21 UTC

i386 or x86_64 ?

Comment 6 Felix Miata 2006-01-25 16:55:43 UTC

i386

Comment 7 Felix Miata 2006-01-28 15:42:53 UTC

Switching to xine is a poor workaround, as it won't play any mp3 files with that engine.

Comment 8 Dirk Mueller 2006-01-30 11:47:57 UTC

I'm currently trying to reproduce the issue you're seeing..

Comment 9 Felix Miata 2006-01-30 12:16:00 UTC

Because Xine would not play mp3s, I switched back to Helix, but the memory leak did not come back with it, at least not so far.

Comment 10 Dirk Mueller 2006-02-07 19:53:44 UTC

ok, its known upstream, and the fix will be part of the next online update  and 10.1. Please reopen if it persists / is again reproduceable.

Comment 11 Dirk Mueller 2006-02-07 19:54:27 UTC

*** Bug 143357 has been marked as a duplicate of this bug. ***