Bugzilla – Bug 142263
memory leak in amarok
Last modified: 2007-07-12 10:16:50 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
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.
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.
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
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
i386 or x86_64 ?
i386
Switching to xine is a poor workaround, as it won't play any mp3 files with that engine.
I'm currently trying to reproduce the issue you're seeing..
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.
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.
*** Bug 143357 has been marked as a duplicate of this bug. ***