Version: 1.2 (using KDE 3.3.2, Arch Linux) Compiler: gcc version 3.4.3 OS: Linux (i686) release 2.6.10-as3-sabine When using the xine-engine for playback, amarok leaks memory. When I start amarok the VIRT usage is about 140mb, after an hour it has gone up with RES about 80mb. After an hour continous playback VIRT is ca. 250mb and RES is about 90mb, according to top output. I recognised that behaviour because an accidental run of top showed a VIRT usage of ca. 450mb after a couple of hours usage. Using the gstreamer-engine with artsd-sink does not produce a memory leak. I use Arch Linux (current) with packages provided by the distro. Amarok is version 1.2, KDE is 3.3.2. xine-lib is version 1.0 provided by the distro. If I can be of further assistance or you need more information, please don't hesitate to ask.
I think this is xine caching and not an actualy memory leak. I noticed this too, and working closely with the devs, we determined that it is not a system memory leak, but just a kernel cachine process. system memory usage stays very steady, and we watched this closely for several hours.
The xine engine does really leak. Valgrind shows this: ==31981== 13944 bytes in 498 blocks are still reachable in loss record 1027 of 1058 ==31981== at 0x1B904E5C: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so) ==31981== by 0x2020C01B: scope_port_put_buffer (xine-scope.c:78) ==31981== by 0x214D2062: vorbis_decode_data (xine_decoder.c:269) ==31981== 1523712 bytes in 498 blocks are still reachable in loss record 1058 of 1058 ==31981== at 0x1B904E5C: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so) ==31981== by 0x2020C064: scope_port_put_buffer (xine-scope.c:81) ==31981== by 0x214D2062: vorbis_decode_data (xine_decoder.c:269) To investigate that further I put debug output in scope_port_put_buffer() (where the malloc()s are) and in scope_dispose() (where the memory should be free()d again). The function scope_dispose() doesn't ever get executed, so all the scope data leaks. I don't know enough about libxine to be able to fix that.
Okay, I found another place (xine-engine.cpp:461) where the memory can be freed, and the memory does get freed, but under certain circumstances there seem to be some leftovers.
The xine engine seems to only leak the mentioned memory when quitting amaroK while it is playing, so it doesn't really matter. Using valgrind I found no evidence that the xine engine leaks memory while playing. Sorry for reopening this bug.
Yeah the buffers are released in XineEngine::timerEvent() The test I did was running xine-engine for 16 hours and checking the memory stats, I didn't get a leak, but maybe I've broken it since.. I'll keep this in mind because several people have now claimed a leak, and even though it may be xine-lib, or xine-lib just caching, it could be our fault.
With swap completely turned off, I observed the following using top: Immediately after starting amaroK, VIRT size is ~102MB. Starting playback increases it by about ~8MB, stopping playback reduces it by the same amount. Seeking or manually skipping tracks doesn't change VIRT, but on every automatic songchange it increases by another ~8MB. VIRT increases until the whole virtual user-address space is used and amaroK crashes.
I can confirm Stefan Siegel's report. Stefan, my original report wasn't that specific, I had not made the connection to the song change yet. I think it would be best to leave this but report closed and you file a new one with the proper description. Pls email me so that I can vote for the new one ;-) Cheers, Dominik
This is a xine bug. From the pthread_join() manpage: "When a joinable thread terminates, its memory resources (thread descriptor and stack) are not deallocated until another thread performs pthread_join on it. Therefore, pthread_join must be called once for each joinable thread created to avoid memory leaks." Xine doesn't seem to call pthread_join on the demuxer thread (I don't know if other threads are also affected) if the demuxer is already finished (because it reached the end of the track).
So I should notify xine-devel?
I had some difficulties getting a sourceforge account for filing a bug report for xine on this. It would be really nice if you could do that, thank you.
I filed a bug against xine at https://sourceforge.net/tracker/index.php?func=detail&aid=1159287&group_id=9655&atid=109655 I'd appreciate if the status of this report could be changed to something actually reflecting the situation.
Thanks! The correct bug status for this situation is RESOLVED INVALID (because it is not an amaroK's fault). I cannot change that directly, so I reopen the bug first...
...and change it to the correct status now.