Memory leak present in xine-lib

Hi Michael,

How do we reproduce the memory leak as I have not noticed in rev 307

The leak was reported to me via email.

"when I am starting it (I am using Ubuntu 7.10 amd64 with Me-TV
0.5.25) it is using 18MB of RAM. 10 hours later (still running for
recording 2h) it is using 227MB."

It's not much to go on but hopefully we can reproduce.

Hi Michael,

Can you please email the person back and ask them how they are running the program, eg is it docked to the panel etc, or asked them to input more info to the bug so it can be reproduced.

couple things I'd like to know to reproducing it is:
a) HD or SD channels
b) docked to the panel or not
c) and what ever else they can tell us

I can only see if this bug can be reproduced and exists under i386 platform as I don't have a 64Bit machine

Definately, I actually asked him to subscribe and he said that he was going to. Maybe LP scared him off ;)

I can't imagine that there will be much difference between the i386 and AMD64 bit.

whilst using development version 308 I have to confirm an encroachment of memory usage over time. watching TV with the EPG turned off I noticed a 100kb increase of memory usage every 2-3 min with out releasing of resources back to the system. Over time this evening the memory used by me-tv had risen up to 165 MB, upon restart this went back to 26.5MB.

So here I am, the person which has got the memory leak.

I have got another 64bit machine with an dvb-t card.... I will test it also there.

Thanks mate. This is an absolute show stopper so I'm glad that you're here to help.

Attaching valgrind output from a run on my box.

Were you guys doing anything with Me TV such as changing channels or starting/stopping recording? Did it just accumulate memory while only playing a channel?

I think that I've got this fixed (Hopefully). I found a small issue with the EPG list not clearing out its list of old widgets properly. Committed in revision 313. Please try it and let me know how you go. Dale reports that he does not see a memory leak. Maybe our EPG isn't as fluid as yours. Or maybe I just haven't fixed it.

So I have tested me-tv on another amd64 machine. The same problem...

I have made some screenshots of the memory me-tv is using when
- starting it (42,8MB);
- about 1h later (67,2MB);
- about 1h later (87,6MB).
No recording, no changing channels, no broadcast... just viewing one channel.

The screenshots are attached at this comment.

That's excellent information! So I'm looking for something that happens while simply viewing a channel. That can only be from the Application::on_timer(). I wonder why this doesn't happen on all machines.

8200, did you try the latest from the bzr repo, 313 ATM?

I have got the latest (0.5.25) from
# Me TV
deb http://ppa.launchpad.net/michael-lamothe/ubuntu gutsy main
deb-src http://ppa.launchpad.net/michael-lamothe/ubuntu gutsy main

I will maybe even test it on a i386 machine (also Ubuntu 7.10).

Hi Michael

after reading this post I went and compiled the latest version (313
development I think) and ran it overnight docked in the icon tray. started
with 26.6 MB of memory used and ended up about 6 hours latter with 104 MB
used.
this was on 10 digital (SD) channel

Thanks Darrin

On Wed, Apr 9, 2008 at 6:31 AM, 8200 <email address hidden> wrote:

> I have got the latest (0.5.25) from
> # Me TV
> deb http://ppa.launchpad.net/michael-lamothe/ubuntu gutsy main
> deb-src http://ppa.launchpad.net/michael-lamothe/ubuntu gutsy main
>
> I will maybe even test it on a i386 machine (also Ubuntu 7.10).
>
> --
> Memory leak present in 0.5.25
> https://bugs.launchpad.net/bugs/212825
> You received this bug notification because you are subscribed to Me TV.
>
> Status in Me TV, it's TV for me computer: Fix Committed
>
> Bug description:
> Needs investigation.
>

Bugger!

Ok, there's a simple (but tedious) process that you can follow to help me find the leak. The trick is to disable some code to stop the leak then slowly start re-enabling parts until we see it again. The tedious part is that each test takes a few hours to see the leak, as you know.

For anyone that is able, here's the list of tasks. For each task insert "return true;", make then test.

1. application.cc, line 509, if this still leaks then I'm very wrong and we should stop this process
2. application.cc, line 511
3. application.cc, line 515
4. application.cc, line 542
5. application.cc, line 551
6. application.cc, line 558
7. application.cc, line 574
8. application.cc, line 580

I've only just started looking into this issue and I'm not sure if I get the same problem. I will start checking tonight.

Hi Michael
sorry to tell you but it fails at line 509 for me tested for about 2 hours
and it rose from 25.5 MB to 36.8 MB upon restart it went back to 25.5MB

Darrin

On Wed, Apr 9, 2008 at 8:52 AM, Michael Lamothe <email address hidden>
wrote:

> Ok, there's a simple (but tedious) process that you can follow to help
> me find the leak. The trick is to disable some code to stop the leak
> then slowly start re-enabling parts until we see it again. The tedious
> part is that each test takes a few hours to see the leak, as you know.
>
> For anyone that is able, here's the list of tasks. For each task insert
> "return true;", make then test.
>
> 1. application.cc, line 509, if this still leaks then I'm very wrong and
> we should stop this process
> 2. application.cc, line 511
> 3. application.cc, line 515
> 4. application.cc, line 542
> 5. application.cc, line 551
> 6. application.cc, line 558
> 7. application.cc, line 574
> 8. application.cc, line 580
>
> I've only just started looking into this issue and I'm not sure if I get
> the same problem. I will start checking tonight.
>
> --
> Memory leak present in 0.5.25
> https://bugs.launchpad.net/bugs/212825
> You received this bug notification because you are subscribed to Me TV.
>
> Status in Me TV, it's TV for me computer: In Progress
>
> Bug description:
> Needs investigation.
>

This might be an issue with another piece of software i.e. driver or a library.

I have confirmed this in 0.5.27

Confirm this also in 0.5.27.
Pentium 4, memory 768 MB, Geforce 6200.
Updated Hardy with latest Nvidia driver.
Started Me TV with 25.9 MB, after 6 hours had gone up to 79.9 MB, ~9 MB/h.

Left Me TV and EPG open as seen in picture.

Does anyone know a version that didn't leak?

The issue seems to be with libxine. If I switch to the mplayer engine then I don't have this issue. There might be something that I'm supposed to be doing.

Also, I have an issue when using the xine player (xine-ui) itself, seems to leak when changing channels.

Can someone please confirm?

HI Michael!

What do you mean with "using the xine player itself"? I just start me-tv with default-settings. Where can I switch between mplayer and xine?

The issue is still there - Ubuntu 8.04 amd64 and ALSO i386!

On my i386 notebook I started it 24h ago (just running in the background - no switching channels / recording). Now it uses 301MB of memory.

On my amd64 PC it uses 27,4MB at the beginning. 40 Minutes later it uses 40,4MB of memory.

In the me-tv.config you can change the "engine_type" to "mplayer". It's not documented or supported but serves as a good test, my fault, sorry.

Ok, I've now added the option to turn off the xine video by setting the "xine.video_driver" to "none" in the config file in the source repository. This confirms it because when I set it to "none" I don't have a leak even though everything else is working because I have audio. There's something wrong with the way Me TV is using libxine to render video.

I've downloaded the source for muxine which is the xine sample application and it leaks noticeably under Hardy. The xine player itself does not seem to leak.

I've also noticed this with totem-xine. Give it a try to see if the same thing happens. Play any MPEG/Flash file.

Confirming this issue with me-tv 0.5.17-1, libxine1 1.1.11.1-1ubuntu3, Ubuntu Hardy. Letting me-tv sit there for 1h watching SD, it started at ~30MB, but linearly grew to ~50MB. Default settings.

Hi Hewus,

The question is not about Me TV. Please try totem-xine and see if the same issue happens to confirm that this is an issue with libxine/xine-lib.

Thanks,

Michael

I can confirm the same memory leak with totem-xine.