System memory/resource leak with repeated vdpau based h264 decode

[seaweed]

Hi,
I am using an ION platform running ubuntu 9.10 and driver version 256.35 to decode an H.264 encoded file repeatedly, running top shows the total system memory used creeping up slowly at a rate of about 8 meg per 15 minutes or so. I suspect that this is being chewed up by XOrg although I cant say for sure. I also tested with mplayer VDPAU patched version 4789364 and the results are the same. Without any video playing, the total system memory looks to be stable. I updated xorg-server package and current version is 2:1.6.4-2ubuntu4.3. Has anybody else seen this problem?

Thanks

[cehoyos]

Originally Posted by seaweed

I also tested with mplayer VDPAU patched version 4789364 and the results are the same.

Are you really sure that this is latest svn? ;-)

If your sample is a transport stream, you have to use -demuxer lavf, -demuxer mpegts eats memory.

Carl Eugen

[seaweed]

Originally Posted by cehoyos

Are you really sure that this is latest svn? ;-)

If your sample is a transport stream, you have to use -demuxer lavf, -demuxer mpegts eats memory.

Carl Eugen

Hi Carl, I just did the quick test with mplayer to see if it happens with mplayer as well, so no I haven't tried the latest mplayer build. Also since I am rendering on multiple child windows, I am seeing much more memory leaks compared to mplayer. BTW valgrind doesnt report any memory leak in my code, so the memory leak that I am talking about probably happens in kernel / possibly due to bugs in glx. After a few days of continuous running, everything become very sluggish. Looks like other people has experienced also.

http://ubuntuforums.org/showthread.php?t=1478329
http://numberedhumanindustries.wordp...fedoras-fault/
http://us.generation-nt.co/help/bug+...s+nv+xaa+c/?or

[Stephen Warren]

seaweed,

You don't mention what application you're seeing this problem in. Is it a custom application?

When you see the repro in MPlayer, can you describe your display configuration, and also provide a bug report? You mentioned that Xorg grows in size. Do you have a compositing manager active? Xorg shouldn't be involved if not. If you do, could you try disabling it, and seeing if that solves the problem?

Thanks.

[seaweed]

Originally Posted by Stephen Warren

seaweed,

You don't mention what application you're seeing this problem in. Is it a custom application?

When you see the repro in MPlayer, can you describe your display configuration, and also provide a bug report? You mentioned that Xorg grows in size. Do you have a compositing manager active? Xorg shouldn't be involved if not. If you do, could you try disabling it, and seeing if that solves the problem?

Thanks.

Hi Stephen, Its a custom app that uses multiple threads to do the VDPAU based decode and render - coupled with ffmpeg (LGPL,dynamically linked). In earlier version I tried to do it with texture from pixmap / GLX and use GL to render multiple windows, but because of performance reason I ditched that and now render decoded video directly into multiple child windows. I disable compiz, this problem still happens after 3/4 days. Well Xorg is used because I request multiple child windows from x server and create multiple prsentation queues from them and run a sequence of these repeatedly in 10 second interval. I am now recompiling the latest version of x server - hopefully this is resolved in version 1.8. I hope the latest nvidia driver will compile along with it.

[Stephen Warren]

seaweed, sorry for the slow response. I'll try to repro the issue today or tomorrow.

Note: I took a look at those links you posted. I don't think any of them are relevant to this issue. The first link seems to be a random "I think have a memory leak" post, and I didn't see any particular common source nor mention of the NVIDIA driver. The 2nd is a core X server issue outside of NVIDIA's control. The 3rd is just a list of bugs from a search, and I think the first entry is the same thing as your 2nd link, and the others didn't seem related.

[Stephen Warren]

seaweed, I believe I've repro'd your problem; on my ION using MPlayer, /proc/meminfo's MemFree went from ~600M to ~300M overnight.

Can you confirm the following:
* Using xrandr or nvidia-settings to change your video resolution doesn't free the leaked memory.
* What about if you VT-switch away?
* What about if you log out of X?
* Killing the X server does free the leaked memory.

Thanks.

[cehoyos]

Originally Posted by Stephen Warren

on my ION using MPlayer, /proc/meminfo's MemFree went from ~600M to ~300M overnight.

Command line (including explicit demuxer specification) or complete, uncut output missing (-demuxer mpegts is eating memory completely independent of VDPAU).

Carl Eugen

[Stephen Warren]

Carl, the test I performed ran MPlayer for about 2 seconds at a time, and then exited MPlayer and restarted it completely. This isn't a memory leak in MPlayer.

[Stephen Warren]

seaweed,

What desktop environment are you using (and please can you supply a bug report which will include e.g. OS details etc.)? I believe I repro'd your problem under Gnome. However, the problem also repros simply running xclock or glxgears for 1s at a time many times. Finally, it didn't repro on a bare X server. Can you try you application running just plain X and maybe a simple window manager and see if your problem goes away?

Thanks.

[seaweed]

Originally Posted by Stephen Warren

seaweed, I believe I've repro'd your problem; on my ION using MPlayer, /proc/meminfo's MemFree went from ~600M to ~300M overnight.

Can you confirm the following:
* Using xrandr or nvidia-settings to change your video resolution doesn't free the leaked memory.

Yes

* What about if you VT-switch away?

By VT did you mean "workspace" in gnome? In that case no it doesn't cleanup the memory

* What about if you log out of X?

doesn't cleanup the memory

* Killing the X server does free the leaked memory.

I am confused about this one, the behaviour I am seeing with my app is when I kill X server, the free memory goes up by a moderate amount but when X is run again, free memory goes down to the level before X was killed - which means it doesn't free the leaked memory (if it did, the free memory would've been the same as when X started the very first time and app wasn't running)

By the way, driver version 256.53 fixes a kernel memory leak, is that anyway related to what we are seeing?

[seaweed]

Originally Posted by Stephen Warren

seaweed,

What desktop environment are you using (and please can you supply a bug report which will include e.g. OS details etc.)? I believe I repro'd your problem under Gnome. However, the problem also repros simply running xclock or glxgears for 1s at a time many times.

Thanks.

Ubuntu 9.10 with gnome, linux kernel 64 bit, version: 2.6.31-20,
xorg version : xorg-server 2:1.6.5+git20091107+server-1.6-branch.2dbcb06a-0ubuntu0sarvatt~karmic
NVIDIA Driver version: 256.44

I ran the following script for about an hour

#!/bin/bash

while true; do
glxgears -fullscreen &
sleep 2
xkill -id $(xwininfo -name glxgears | grep "Window id" | cut -d' ' -f4)
done

Here is the results:

before running script, with x running (all in MB):

used : free: total:
44480 1494828 1539308


After running script, with x running :

used : free: total:
544201 995107 1539308


After exiting to console:

used : free: total:
544201 995107 1539308


After killing X:

used : free: total:
454201 1085107 1539308


After restarting X:

used : free: total:
507776 1031532 1539308

Finally, it didn't repro on a bare X server. Can you try you application running just plain X and maybe a simple window manager and see if your problem goes away?

I will do it but I don't think this is an issue, I will confirm