Bug 100039

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.