Bug 100039 - amarok leaks memory when using xine engine
Summary: amarok leaks memory when using xine engine
Status: RESOLVED NOT A BUG
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-22 23:35 UTC by C. Dominik Bódi
Modified: 2006-06-11 12:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description C. Dominik Bódi 2005-02-22 23:35:01 UTC
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.
Comment 1 Greg Meyer 2005-02-26 04:16:09 UTC
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.
Comment 2 Stefan Siegel 2005-02-26 22:49:06 UTC
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.
Comment 3 Stefan Siegel 2005-02-27 02:33:47 UTC
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.

Comment 4 Stefan Siegel 2005-02-27 04:43:40 UTC
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.
Comment 5 Max Howell 2005-02-28 13:43:55 UTC
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.
Comment 6 Stefan Siegel 2005-02-28 22:05:36 UTC
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.

Comment 7 C. Dominik Bódi 2005-03-01 18:27:25 UTC
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
Comment 8 Stefan Siegel 2005-03-04 12:26:38 UTC
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).

Comment 9 Max Howell 2005-03-06 01:14:52 UTC
So I should notify xine-devel?
Comment 10 Stefan Siegel 2005-03-08 17:00:11 UTC
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.

Comment 11 C. Dominik Bódi 2005-03-08 20:07:59 UTC
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.
Comment 12 Stefan Siegel 2005-03-08 21:20:23 UTC
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...
Comment 13 Stefan Siegel 2005-03-08 21:21:50 UTC
...and change it to the correct status now.