Memory leak in nvidia-glx-new's GL_EXT_texture_from_pixmap

[Matt Price]

Binary package hint: compiz

Running gutsy [uptodate as of saturday, oct 6, 2007] with compiz enabled & custom effects, using non-free nvidia driver, compiz's memory use slowly climbs while performance degrades; after ~ 36 hours it had risen to 43% of my 1 Gi of RAM (according to top). Workaround is to issue metacity --replace & and then compiz --replace &; i guess the first step can probably be left out but i didn't testthat just now.

in other cases the slowdown was so bad that the system was for all intents and purposes frozen, and gdm had to be restarted remotely (and veeeerrrry slowly).

anything i can do to help track down the source of the bug.

[Matt Price (matt-price)]

ps, it appears that using vlc greatly accelerates the rate of slowdown. watching a random playlist of ripped avi files, i saw memory use go to 51.3% of 1 Gig RAM in about 45 minutes. stopping compiz took longerthan 2 minutes, performance was so degraded.

[Travis Watkins (amaranth)]

I use nvidia too and run compiz for a week at a time with no problems. Are you using nvidia-glx or nvidia-glx-new?

[sampsa (sampsa-hamalainen)]

I can confirm this on a hp dv2000 laptop with an nvidia geforce 7200 (128MB) card with gutsy and nvidia-glx-new (100.14.19).

compiz.real hogs all my memory (1GB) in a couple of hours when having several windows open and, for instance, surfing the web. Closing the windows doesn't free the memory, it is only freed by stopping or restarting compiz.

I don't know if this is caused by the new "GLX_EXT_texture_from_pixmap out-of-memory"- handling in the newest nvidia driver, which fixed the black window bug. In my understanding, the black window bug was caused by the graphics card running out of memory. Even if the nvidia driver was borrowing memory from the system, the amount seems a bit unreasonable, 800MB for some 8 windows.

If there is any information that might be helpful I'll gladly post it.

[jnewton (nevion)]

I seem to be affected by this as well and under similar circumstances (100.14.19 on a 8800gts). I've only recently started using compiz again, but after about a day of normal usage, I have over a gigabyte missing with no process to blame... this didn't happen w/ only metacity.. Removing nvidia module freed a good chunk of memory (200-300 or so megs) w/ passed attempts, but I still had the remainder of the memory missing with it and all services stopped, with the amount of memory listed from ps no where near the amount reported by free (where'd my mem go?). Only solution for me has been frequent rebootings :-(.

[Matt Price (matt-price)]

On Wed, 2007-10-10 at 10:54 +0000, Travis Watkins wrote:
> I use nvidia too and run compiz for a week at a time with no problems.
> Are you using nvidia-glx or nvidia-glx-new?
>
hi travis,

i'm using nvidia-glx-new, like the other respondents on this bug. my
graphics card is a Geforce Go 7400, on a dell latitude d820.

right now i can't do further testing because, following the latest
update, i can't load x using the nvidia module (bug
https://bugs.launchpad.net/bugs/151213 ). but hopefully i'll be able to
work on that soon, so if you have any advice / would like more
information, please lte me know.

thanks for the prompt response!

matt

> ** Changed in: compiz (Ubuntu)
> Status: New => Incomplete
>
--
Matt Price
<email address hidden>

[Travis Watkins (amaranth)]

Ok now I'm just confused. You have the same video hardware as me and are using the same driver.

[Matt Price (matt-price)]

hmm, maybe there's a plugin that causes the issue. unfortunately i
can't test it right now b/c nvidia refuses to load at all! not sure
what the issue is, maybe some kind of mismatch.

anyway, attached is my compiz profile, maybe a diff with yours would
suggest a starting point?

thanks again,

matt

On Wed, 2007-10-10 at 23:48 +0000, Travis Watkins wrote:
> Ok now I'm just confused. You have the same video hardware as me and are
> using the same driver.
>
--
Matt Price
<email address hidden>

[crashhandler]
as_enabled = true
as_start_wm = false
as_wm_cmd =

[core]
as_active_plugins = dbus;decoration;move;place;png;regex;resize;svg;video;wobbly;animation;imgjpeg;neg;resizeinfo;ring;snap;text;workarounds;vpswitch;extrawm;fade;cube;rotate;scale;switcher;expo;ezoom;cubecaps
as_texture_filter = 1
as_click_to_focus = true
as_autoraise = true
as_autoraise_delay = 1000
as_close_window = <Alt>F4,Button0,,0,false
as_main_menu = <Alt>F1,Button0,,0,false
as_run = <Alt>F2,Button0,,0,false
as_command0 =
as_command1 =
as_command2 =
as_command3 =
as_command4 =
as_command5 =
as_command6 =
as_command7 =
as_command8 =
as_command9 =
as_command10 =
as_command11 =
as_run_command0 = ,Button0,,0,false
as_run_command1 = ,Button0,,0,false
as_run_command2 = ,Button0,,0,false
as_run_command3 = ,Button0,,0,false
as_run_command4 = ,Button0,,0,false
as_run_command5 = ,Button0,,0,false
as_run_command6 = ,Button0,,0,false
as_run_command7 = ,Button0,,0,false
as_run_command8 = ,Button0,,0,false
as_run_command9 = ,Button0,,0,false
as_run_command10 = ,Button0,,0,false
as_run_command11 = ,Button0,,0,false
as_slow_animations = <Shift>F10,Button0,,0,false
as_raise_window = ,<Control>Button6,,0,false
as_lower_window = ,<Alt>Button6,,0,false
as_unmaximize_window = <Alt>F5,Button0,,0,false
as_minimize_window = <Alt>F9,Button0,,0,false
as_maximize_window = <Alt>F10,Button0,,0,false
as_maximize_window_horizontally = ,Button0,,0,false
as_maximize_window_vertically = ,Button0,,0,false
as_opacity_increase = ,<Alt>Button4,,0,false
as_opacity_decrease = ,<Alt>Button5,,0,false
as_command_screenshot = gnome-screenshot
as_run_command_screenshot = Print,Button0,,0,false
as_command_window_screenshot = gnome-screenshot --window
as_run_command_window_screenshot = <Alt>Print,Button0,,0,false
as_window_menu = <Alt>space,<Alt>Button3,,0,false
as_show_desktop = <Control><Alt>d,Button0,,0,false
as_raise_on_click = true
as_audible_bell = true
as_toggle_window_maximized = <Alt>F10,Button0,,0,false
as_toggle_window_maximized_horizontally = <Control><Alt>h,Button0,,0,false
as_toggle_window_maximized_vertically = <Control><Alt>v,Button0,,0,false
as_hide_skip_taskbar_windows = true
as_toggle_window_shaded = <Control><Alt>s,Button0,,0,false
as_ignore_hints_when_maximized = true
as_command_terminal =
as_run_command_terminal = <Control><Alt>x,Button0,,0,false
as_cursor_theme = default
as_cursor_size = 18
as_ping_delay = 5000
s0_detect_refresh_rate = true
s0_lighting = true
s0_refresh_rate = 60
s0_hsize = 4
s0_vsize = 1
s0_opacity_step = 10
s0_unredirect_fullscreen_windows = true
s0_default_icon = icon
s0_sync_to_vbla...

[Travis Watkins (amaranth)]

If I had to guess I'd say cube, rotate, or (most likely) cubecaps.

[sampsa (sampsa-hamalainen)]

> If I had to guess I'd say cube, rotate, or (most likely) cubecaps.

Of these plugins, I have cube and rotate enabled and cubecaps disabled.

I can post my compiz profile here as well if it helps but I couldn't figure where to find it from..

[Travis Watkins (amaranth)]

Do either one of you get this problem with the default settings for compiz?

[Evan (ev)]

Perhaps it's ring? Compiz was using 40something percent of my memory (roughly 800MB) when leaving it running for a day or two, when I noticed that I was using Custom Effects. Switching back to Extra Effects, compiz's memory usage has not climbed above 11 percent in the 12 hours it's been running.

I'll follow up tomorrow after it's had a full 24 hours to sit, then test with and without ring to confirm.

[Matt Price (matt-price)]

On Fri, 2007-10-12 at 03:45 +0000, Evan Dandrea wrote:
> Perhaps it's ring? Compiz was using 40something percent of my memory
> (roughly 800MB) when leaving it running for a day or two, when I noticed
> that I was using Custom Effects. Switching back to Extra Effects,
> compiz's memory usage has not climbed above 11 percent in the 12 hours
> it's been running.
>
back when i filed this bug, and could still use compiz at all... i did
use ring a lot, as my main switcher. i'd be sorry to see it go!

matt

> I'll follow up tomorrow after it's had a full 24 hours to sit, then test
> with and without ring to confirm.
>
--
Matt Price
<email address hidden>

[Evan (ev)]

Travis,

It's still occurring with Extra Effects, rather than just Custom Effects as I hypothesized above:
evan 6248 0.6 44.6 310848 914552 ? SL Oct11 11:37 /usr/bin/compiz.real

It might be worth noting that this issue did not occur for me with the old nvidia driver (the one with the black windows bug). Would it be worth it to try with Normal Effects or a specific selection of plugins, or does this appear to be Nvidia's problem?

Thanks

[Matt Price (matt-price)]

On Sat, 2007-10-13 at 04:24 +0000, Evan Dandrea wrote:
> Travis,
>
> It's still occurring with Extra Effects, rather than just Custom Effects as I hypothesized above:
> evan 6248 0.6 44.6 310848 914552 ? SL Oct11 11:37 /usr/bin/compiz.real
>
> It might be worth noting that this issue did not occur for me with the
> old nvidia driver (the one with the black windows bug). Would it be
> worth it to try with Normal Effects or a specific selection of plugins,
> or does this appear to be Nvidia's problem?
>
> Thanks
>

as of today nvidia works again on my machine (i'm hypothesizing some
kind of sustained kernel module mismatch or something, as there've been
frequent updates). Tried compiz with various configurations and saw the
same memory leak & general performance degradation as before. disabling
the cube had no effect, still saw the same problems; but disabling the
ring switcher thereafter seems to have fixed the problem (i'll leave it
up for a day or so to confirm). i'm very sorry about that as the ring
switcher is about the only effect that i really really like in compiz (i
want to like zoom, too, but am having trouble finding a use for it).
travis, should i file a different bug against the ring switcher?

matt

--
Matt Price
<email address hidden>

[Travis Watkins (amaranth)]

No need, this bug report is enough.

[sampsa (sampsa-hamalainen)]

I was never using ring while having the problem, so for me it can't really be the ring. I experimented with different setups as well and I get the same effect always. With less effects enabled, "normal" in the appearance dialog for instance, it just takes longer to fill my memory.

So if it's not the plug-ins, could it be the way compiz interacts with the nvidia driver, or just driver. I sort of get the feeling that in the same situations where I used to start getting black windows, my memory now starts filling up. I'll be happy to do any specific tests if you feel they might be helpful.

thanks

[Danny Baumann (dannybaumann)]

Although I'm obviously biased (as the one who wrote ring), I have to say that I really, really doubt there is a leak that may fill several hundred megabytes of memory inside ring.
Besides the usual boilerplate code that every compiz plugin has, there is only one place of allocation where a 8 byte structure is allocated for each window in the ring. So even if it wasn't freed correctly (which it is here), it would take ages to fill up memory with that allocation, unless you have a really absurd amount of windows in the ring.
The second place where stuff is allocated from ring is the window title display (which is also freed just fine here) ... if you want to check that, just disable either the window title display or the text plugin.

For me, the issue sounds like a driver problem, just as sampsa wrote before me.

[Chris McCauley (chris-avondalepark)]

Hi,

I'm not using ring, nor desktop cube - just the "extra effects" and top shows my nvidia.real using the following virtual = 489M, Resident = 421M and that's just over the course of three hours with no video playback. Yesterday I experienced several restarts of the desktop and dmesg showed processes being killed due to a lack of available memory. Most likely there's a bug in either nvidia (mine is a Ge Force 5200) or the core compiz.

Chris

[Matt Price (matt-price)]

On Tue, 2007-10-16 at 05:54 +0000, Danny Baumann wrote:
> Although I'm obviously biased (as the one who wrote ring), I have to say that I really, really doubt there is a leak that may fill several hundred megabytes of memory inside ring.
> Besides the usual boilerplate code that every compiz plugin has, there is only one place of allocation where a 8 byte structure is allocated for each window in the ring. So even if it wasn't freed correctly (which it is here), it would take ages to fill up memory with that allocation, unless you have a really absurd amount of windows in the ring.
> The second place where stuff is allocated from ring is the window title display (which is also freed just fine here) ... if you want to check that, just disable either the window title display or the text plugin.
>
> For me, the issue sounds like a driver problem, just as sampsa wrote
> before me.
>
i unfortunately seem to have spoken too soon. after about 15 hours with
the ring disabled, my usage is creeping up, from around 20M now up to
75M, and I expect it will continue to rise. sorry about that. the
creep was much much faster when ring *was* enabled, but maybe my usage
pattern was different as well.

matt

--
Matt Price
<email address hidden>

[militanz (matteo-comisso)]

Same problem here, with an hp Pavilion dv2000, 1GB Ram, probably like sampsa... Nothing special to say, only another feedback for this boring situation!

militanz

[Ramesh Dharan (rrdharan)]

Is it possible to change the title of this bug? Something like "compiz leaks memory with NVIDIA proprietary driver" (or similar)?

I just filed a new bug about compiz leaking memory and I ignored this one because the title said it only affected the Ring plugin which I never use.

On my machine, it's *really* bad. I see resident memory usage increase by ~3MB each time I open a window.

*Sigh*. So I can't run Compiz on my work machine, because it leaks memory like crazy with NVIDIA cards. And I can't run it at home, because it locks up my laptop with an ATI Mobility 9600. Are Intel cards the only ones that can actually run this damn thing? What gives?

[Ramesh Dharan (rrdharan)]

I should also add that the amount of memory leaked appears to be (somewhat unsurprisingly) proportional to the size of the window.

That is to say, if I open and close a new firefox window, I see compiz resident memory jump by ~10MB. With a smaller terminal window, it's ~3MB as noted before.

[klerfayt (klerfayt-deactivatedaccount)]

what happens if you maximize/restore a window about 20 times?
https://bugs.freedesktop.org/show_bug.cgi?id=12613
also I believe that 50MB for a start is not normal by itself with compiz-core&compiz-kde packages only?

[cuby (cuby)]

Same here.
I have an nvidea card, core2duo and 1GB ram. I've the upgrade from feisty during the beta stage of gutsy.
Last night I had to shutdown the computer because compiz.real consumed all memory and the machine turn unusable.

[tombrus (tombrus)]

Same here.

Just upgraded from Feisty to Gutsy. When I maximize/minimize windows compiz eats my memory eagerly. I switched window resizing from the default 'outline' to 'normal' and that seems to worsen things: resizing then also eats memory by the meg. I attached a log of 'ps aux' of compiz each second and you can see it grow from 32M to 256M in 80 seconds! I have no idea what module causes this.

i.m.h.o "medium" for this bug is a bit too careful, I would like to see this upped a bit.

-Tom

[Chris McCauley (chris-avondalepark)]

I agree with Tombrus, this appears to be a critical failure in Compiz.
Hopefully this will get fixed very quickly

tombrus wrote:
> Same here.
>
> Just upgraded from Feisty to Gutsy. When I maximize/minimize windows
> compiz eats my memory eagerly. I switched window resizing from the
> default 'outline' to 'normal' and that seems to worsen things: resizing
> then also eats memory by the meg. I attached a log of 'ps aux' of compiz
> each second and you can see it grow from 32M to 256M in 80 seconds! I
> have no idea what module causes this.
>
> i.m.h.o "medium" for this bug is a bit too careful, I would like to see
> this upped a bit.
>
> -Tom
>
> ** Attachment added: "ps of compiz with one line/sec"
> http://launchpadlibrarian.net/10106768/compiz-ps
>
>

[Hotpocketdeath (hotpocketdeath)]

Well, add another to the list.

I am running Gutsey on a HP DV2200 w/ a geforce go 7200 and I also get this bug. I'm using custom effects from Compiz Fusion as well. System Monitor shows compiz.real eating 330Virtual and 310 resident memory.

My memory keeps climbing and it will eventually get to the point where I am out of system memory and and my HDD starts thrashing from the swap. This eventually leads to a complete system crash and I have to restart Ubuntu completely.

I agree with Chris. This is a catastrophic memory leak. It really needs to be fixed.

[Chris Halse Rogers (raof)]

I've tried this, and it's not a problem with any plugin.

Under nvidia-glx-new, I ran compiz with no plugins enabled, spawned 100 gnome-terminals then killed them. compiz.real's shared memory size increased by ~150Mb and didn't decrease on closing the terminals. Spawning another 100 terminals resulted in a further ~150Mb increase, and so on.
Running under nvidia-glx I tried the same thing and the compiz memory usage appeared stable. However, the 96xx drivers really didn't like running compiz, so it'd be good to get some confirmation from someone else here.

It looks very much like this is a bug in the nvidia-glx-new drivers.

Interestingly, trying to spawn 200 gnome terminals at once crashes X :).

[beniwtv (beniwtv-deactivatedaccount)]

I can confirm this.

Running a HP Pavilion dv6106 Laptop with a Nvidia 6150 and nvidia-glx-new.

I'm with tombrus that "medium" is to cafeful, and should be upped a bit, as it seems to be affecting all people with the new nvidia drivers.

Then again this could be a bug in the new Nvidia drivers, in that case we should make sure Nvidia knows about it, and release a update for Gutsy once the problem is solved.

I hope this gets fixed soon...

Cheers :)

[Travis Watkins (amaranth)]

Seems this is a driver problem.

[tombrus (tombrus)]

Salvation seems near: on tweakers.net I just saw an update of the nvidia drivers to 100.14.23 (I currently have 100.14.19). The release highlights mention: "Fixed a problem with a Compiz after vt-switching".

-Tom

[Matt Price (matt-price)]

On Mon, 2007-10-22 at 18:26 +0000, tombrus wrote:
> Salvation seems near: on tweakers.net I just saw an update of the nvidia
> drivers to 100.14.23 (I currently have 100.14.19). The release
> highlights mention: "Fixed a problem with a Compiz after vt-switching".
>
i don't think that's our bug. it would be nice if there was some way to
contact the nvidia engineers and actually get a response... hopefuly
the growing number of users reporting this bug will somehow get this to
their attention. does anyone know whether there are people using recent
nvidia hardware under gutsy who AREN'T affected by this bug?

matt

> -Tom
>
--
Matt Price
<email address hidden>

[Matt Price (matt-price)]

I've started a forum thread on nvnews about this issue; maybe someone
will report a workaround or something. and james jones an nvidia has
responded to an email on compiz.net & entered this bug into their
system. so maybe this'll get osme attention from them.

the nvidia forum url is :
http://www.nvnews.net/vbulletin/showthread.php?p=1420886#post1420886

matt

Matt Price
<email address hidden>

[yellowbread (filbert1)]

Don't be so quick to point the finger at nvidia. I removed the nvidia drivers and found the same behavior. Often, not all the memory a window uses gets freed upon closing the window, and streaming applications, music, video, seem to leave behind about 20% of the data they process in memory. In all the memory loss didn't seem any different with nvidia/compiz or without.

Carl Darby

[Travis Watkins (amaranth)]

If you're not using the nvidia driver you're not using compiz so you couldn't be seeing a 'memory leak in compiz'.

[yellowbread (filbert1)]

Travis, that's my exactly my point. With the nvidia driver, I was seeing the same behavior as described here. While running top, I could see the resident memory used by compiz.real rising steadily. Then I removed the nvidia driver. Of course compiz.real was no longer one of the running processes, but the increase in memory usage overall followed the same pattern as before, there was just no particular process to attribute it to. So, I either have at least two separate massive memory leaks, or neither the nvidia driver nor compiz are responsible for it.

Carl Darby

[Matt Price (matt-price)]

On Tue, 2007-10-23 at 11:41 +0000, yellowbread wrote:
> Travis, that's my exactly my point. With the nvidia driver, I was
> seeing the same behavior as described here. While running top, I could
> see the resident memory used by compiz.real rising steadily. Then I
> removed the nvidia driver. Of course compiz.real was no longer one of
> the running processes, but the increase in memory usage overall followed
> the same pattern as before, there was just no particular process to
> attribute it to. So, I either have at least two separate massive memory
> leaks, or neither the nvidia driver nor compiz are responsible for it.
>
just fyi, i do *not* see this pattern, and I think most of the original
contributors to the bug also don't. Is the memory just getting lost in
the abyss? is it stashed under Xorg? like i say, i don't see this
behaviour on my currently running nvidia/metacity system (been running
for over a week now).

matt

> Carl Darby
>
--
Matt Price
<email address hidden>

[Chris McCauley (chris-avondalepark)]

Hi,

I agree with Matt, this problem does not seem to happen with the
nvidia/metacity combination. That doesn't mean that it is definitely a
compiz problem though - the "black windows" problem with earlier nvidia
drivers running out of video memory was only seen with beryl and nvidia.

Chris

Matt Price wrote:
> On Tue, 2007-10-23 at 11:41 +0000, yellowbread wrote:
>
>> Travis, that's my exactly my point. With the nvidia driver, I was
>> seeing the same behavior as described here. While running top, I could
>> see the resident memory used by compiz.real rising steadily. Then I
>> removed the nvidia driver. Of course compiz.real was no longer one of
>> the running processes, but the increase in memory usage overall followed
>> the same pattern as before, there was just no particular process to
>> attribute it to. So, I either have at least two separate massive memory
>> leaks, or neither the nvidia driver nor compiz are responsible for it.
>>
>>
> just fyi, i do *not* see this pattern, and I think most of the original
> contributors to the bug also don't. Is the memory just getting lost in
> the abyss? is it stashed under Xorg? like i say, i don't see this
> behaviour on my currently running nvidia/metacity system (been running
> for over a week now).
>
> matt
>
>
>
>> Carl Darby
>>
>>

[yellowbread (filbert1)]

Ah, so maybe I do have two separate leaks. I'll sit back and listen until I learn more about how this all works.

Carl

[yellowbread (filbert1)]

I don't know if this will help any of you, but running in a xgl session seems to have fixed the memory leak with compiz. Now to figure out whats going on with the streaming stuff.

Carl

[dirk (dirk-kuijsten)]

According to Nvidia, it is a bug in the Nvidia driver and will be fixed in the next release, whenever that is.
see: http://www.nvnews.net/vbulletin/showpost.php?p=1442530&postcount=15

[Tessa (unit3)]

Replies on that thread seem to indicate there's a newer driver and it's still broken, so I guess we can't expect any fix right away?

[klerfayt (klerfayt-deactivatedaccount)]

I would expect it to be still broken if it isn't mentioned in driver
release notes ;-)

On Nov 20, 2007 8:57 PM, Graeme Humphries <email address hidden> wrote:
> Replies on that thread seem to indicate there's a newer driver and it's
> still broken, so I guess we can't expect any fix right away?
>
> --
> Memory leak in nvidia-glx-new's GL_EXT_texture_from_pixmap
> https://bugs.launchpad.net/bugs/151168
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Murat Gunes (mgunes)]

> I would expect it to be still broken if it isn't mentioned in driver
> release notes ;-)

I wouldn't. NVIDIA have inadvertantly fixed various bugs in past driver
releases.

[klerfayt (klerfayt-deactivatedaccount)]

release notes:
http://www.nvidia.com/object/linux_display_ia32_169.04.html

On Nov 21, 2007 12:13 AM, Murat Güneş <email address hidden> wrote:
>
> > I would expect it to be still broken if it isn't mentioned in driver
> > release notes ;-)
>
> I wouldn't. NVIDIA have inadvertantly fixed various bugs in past driver
> releases.
>
> --
>
> Memory leak in nvidia-glx-new's GL_EXT_texture_from_pixmap
> https://bugs.launchpad.net/bugs/151168
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Matthew Tighe (tighem)]

I'm still seeing this issue under 169.04. Over on the NV forum, the developers are pretty surprised to hear others are seeing it too. I think the issue is in the animations plugin. Just turning it on and off causes memory usage to start increasing. I'm leaving it off for now to see how things run today.

[Daniel J Blueman (danielblueman)]

$ cat /proc/5654/status
Name: compiz.real
State: S (sleeping)
SleepAVG: 98%
Tgid: 5654
Pid: 5654
PPid: 5547
TracerPid: 0
Uid: 1842 1842 1842 1842
Gid: 100 100 100 100
FDSize: 64
Groups: 4 20 24 25 29 30 44 46 100 104 108 109 110 115 117 201 903
VmPeak: 1765884 kB
VmSize: 290624 kB
VmLck: 1467160 kB
VmHWM: 1482256 kB
VmRSS: 1482056 kB
VmData: 101960 kB
VmStk: 140 kB
VmExe: 220 kB
VmLib: 21112 kB
VmPTE: 3448 kB
Threads: 1
SigQ: 0/16253
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000020001000
SigCgt: 0000000180014003
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000004000
Cpus_allowed: 03
Mems_allowed: 00000000,00000001

This is a pretty bad leak, since the memory is locked by the driver (normally, a non-root process can lock 8 or so KB max), and is clearly pages marked by the driver, as everything in /proc/<pid>/maps is (more or less) as expected.

I can't believe nvidia don't have infrastructure for an automated test for this.

[Aaron Ang (aaron-polity)]

Nice to see that others have the same problems as me. (roughly speaking :P)

Linux straylight 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Intel Centrino 1.8Ghz, 1GB RAM, nVidia Geforce Go 6200.

After a random amount of time, everything slows down, making it completely unusable, forcing me to reboot the x server. Don't know if this is related, but usually when right clicking for the context menu, it takes longer to appear, and briefly showed garbled colored lines before it shows properly.

I'm not quite show how to display my current nvidia version, but I'm pretty sure it's the latest one, I've always installed available updates. I'm seriously thinking about going back to XP because I can't use it for day to day stuff, and just go without the compiz fusion coolness.

[Jeremy Akers (irwinr12)]

I'm not sure if I'm having the same issue, but I am experiencing some severe memory issues. After a reboot, free -m looks like this:

jeremy@dell:~$ free -m
             total used free shared buffers cached
Mem: 3033 724 2309 0 29 406
-/+ buffers/cache: 288 2745
Swap: 3773 0 3773

As you can see, I have 3GB of memory, and I'm using less than 300MB. No big deal. However, over the course of a week, the +/- buffers/cache line slowly increases to nearly 3GB. Running top and hitting shift + M does not show any processes hogging memory. In fact, the list looks almost identical to what it looks like immediately after a reboot. No more than 150 processes, and none are using higher than normal amounts of memory. And even if I shut down -everything- on my box, including GDM, X server, etc, and login to the console on CTRL-ALT-F2, my memory usage does not decrease at all.

I'm -guessing- this is some sort of kernel level driver leak with the nvidia driver, based on what I've read from others. But I do not know how to confirm this. Is there a way to get the kernel to print a mapping of it's internal address space to determine what's using this memory? Or does anyone have any other suggestions as to what to try?

I'm running Ubuntu 7.10, without Compiz (I completely uninstalled it)

The following packages are installed, related to nvidia:

linux-restricted-modules-2.6.20-15-generic
linux-restricted-modules-2.6.20-16-generic
linux-restricted-modules-2.6.22-14-generic
nvidia-glx-1:1.0.9639+2.6.22.4-14.10
nvidia-kernel-common-20051028+1ubuntu7
xserver-xorg-video-nv-1:2.1.5-1ubuntu1

My card, according to lspci -v

01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 LE] (rev a1) (prog-if 00 [VGA])
        Subsystem: Dell Unknown device 0405
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at dd000000 (32-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at de000000 (64-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at dfe00000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [78] Express Endpoint IRQ 0

[kahon (kahon-f)]

I don't read all. Sorry my english. I'm spanish. I had this problem, but I had reading this forum. I uninstall the package emerald. I don't have this problem!! All right!! :D.

Try this solutions, I wait all right for all ;). Byeeeee!

[kahon (kahon-f)]

Sorry, I see top now, and it isn't true. I have the problem :S. Hop.

[SkyScrap (andreas-ebbert)]

Hi,

just wanted to confirm that the workaround posted by evilspy (increasing the memory in the BIOS) worked fine for me.

Andreas

[Timo Aaltonen (tjaalton)]

Confirmed on Hardy with 169.09.

[css (csilver)]

This may be fixed...but it hasn't made it into general updates yet...

         http://www.nvidia.com/object/linux_display_x86_96.43.05.html

At least it's on the radar,

cs

[Timo Aaltonen (tjaalton)]

No, that fix means that new windows are not "empty" anymore. This bug is about compiz memory consumption growing until you have to kill it. That package is in Hardy already.

[Daniel Lombraña González (teleyinex)]

I have the same problem, I have Ubuntu Gutsy the Gibbon with a nvidia GeForce Go 7400 card and using nvidia-glx-new from the repositories. I have modified the compiz script from /usr/bin/ and changed the option INDIRECT="no" to "yes", and now compiz.real is always at 19.7 MB while without this option compiz was getting like 500 MB of my 1GB, something horrible.

[gnychis (gnychis)]

i strongly suggest all users experiencing this problem to voice their concern to nvidia, rather than to ubuntu.

nvnews is a great place for this, as nvidia staff monitor it. Several nvidia staff have already replied to an ongoing thread, but have not been able to reproduce the problem. If we can help them reproduce it, we can possibly get this resolved.

Please, if you can, chime in to the following thread so we can get this moving:
http://www.nvnews.net/vbulletin/showthread.php?t=100803

The more that respond and voice concern, the higher nvidia will make it a priority, hopefully.

[urys (irychtar)]

Confirmed on Hardy with 171.06

[klerfayt (klerfayt-deactivatedaccount)]

If you want this bug fixed then send the affected hardware to nvidia corporation. They "have issues reproducing the memory leak with hardware available to them" ... by their own words.

[frank (frank-lux-it)]

just to confirm Daniel Lombraña observation, the changed option INDIRECT="no" to "yes" in /usr/bin/compiz worked for me too (gutsy, 169.12 w/ twinview on a NVS-285)

[ccc1 (cllccl-deactivatedaccount)]

yeah they can't reproduce it cause they are using cards with too much memory. As someone wrote somewhere this problems disappears if one has enough videomemory. So instead of sending nvidia hardware, they should test with a mainboard with integrated nvidia graphics set videomemory to 32MB. Then they should be able to reproduce the bug ...

[urys (irychtar)]

I was installed new Beta 173.08 yeasterday on HH 8.04. NO MEMORY LEAKS NOW!

[urys (irychtar)]

Kernel 2.6.24-15 and 2.26.24-15

[klerfayt (klerfayt-deactivatedaccount)]

thanks for the notice urys!
Confirmed:
nvidia beta drivers 173.08 do not leak memory in Kubuntu 7.10 with geforce go 6200 turbocache 128MB graphics card

here is what you need to do in gutsy before you run nvidia beta drivers installer:

sudo apt-get remove --purge nvidia-kernel-common
sudo apt-get install libc6-dev pkg-config xserver-xorg-dev
sudo /etc/init.d/kdm stop or sudo /etc/init.d/gdm stop

[SeRpEnT (superbes)]

I confirm, the new beta driver 173.08 on Hardy (2.6.24-16-generic) solve the memory leak problem!!!

Before installing I used the klerfayt's procedure:

sudo apt-get remove --purge nvidia-kernel-common
sudo apt-get install libc6-dev pkg-config xserver-xorg-dev
sudo /etc/init.d/kdm stop or sudo /etc/init.d/gdm stop

PS I have a GeForce 6400 128MB turbocache

[Luis Alberto Pabón (copong)]

Any chance of getting this driver in Hardy, or is it too beta and too close to Hardy release?

[Tessa (unit3)]

Unlikely to get into Hardy simply because it is a beta driver.

However, with envyng in hardy, it makes it pretty painless for users to upgrade to it.

[Yura Tolstik (yltsrc)]

memory leak confirmed when i am closing windows with enabled compiz & nvidia-glx-new

[DickeyWang (hwang313000)]

Too bad 173.08 is a beta driver, and EnvyNG's author clearly states that he would only include stable driver in EnvyNG. I hope Nvidia will soon release their new stable driver, 169.12 not only has this memory leak problem but also couldn't detect the correct EDID information on certain laptops (my 14" Thinkpad T61p is one of them).

[Dave Vree (hdave)]

173.14 has been released by nVidia

http://www.nvnews.net/vbulletin/showthread.php?t=113919

No mentioned of having fixed a memory leak. Anyone know when it will show up in the repos anywhere?

[Alberto Milone (albertomilone)]

Can you enable the hardy-proposed and hardy-updates repositories, install EnvyNG so as to install the latest release of the driver?

In any case this is definitely a bug which we can't fix. NVIDIA should deal with it.

[klerfayt (klerfayt-deactivatedaccount)]

to avoid any confusion, the memory leak has been fixed since:
nvidia beta drivers 173.08

[ccc1 (cllccl-deactivatedaccount)]

any chance getting the just released stable nvidia driver 173.14.12 via a hardyupdate or do we have to wait till 8.10?

[Tessa (unit3)]

I suspect it won't be in hardy-updates, but that it will be available via envy-ng. Confirm with the envy project, however.

[Alberto Milone (albertomilone)]

ccc1, Graeme: the driver will be available through envyng ASAP.

[Tessa (unit3)]

That's what I figured. Thanks again for all your hard work on the envy project, Alberto. It really makes things a lot less painful for us NVidia users. :)

[ccc1 (cllccl-deactivatedaccount)]

i think the nvidia-driver should be also updated for users that don't use envy-ng. This is a quite critical bug that can lead to data-loss. for example the kernel killed once my virtualbox-session cause there wasn't any free memory left ...

[Daniel J Blueman (danielblueman)]

This bug is still prevalent in 8.04.1 as of 2008-08-20; as the current nvidia driver (169.12+2.6.24.13-19.45) sets a flag in the pages used to map textures from, and the flag isn't cleared on the correct path, allocated pages get locked. There is a (userspace) per-process 32KB locked limit for good reason, yet we're seeing gigabytes being locked (drivers can do what they want), which is catastrophic.

This ultimately leads to a fatal OOM situation; the OOM killer doesn't guarantee that compiz.real will get killed, however all workflow is lost, as the system will be paging and with little or zero pagecache; page reclamation logic will be scanning for pages to reclaim and desperately shrinking pools - everything will suffer.

Basically, this single bug destroys your uptime, forcing workarounds and risk for technical users catching it in time; indeed it is (was, will be) the biggest productivity-eater I've experienced (much like windows updates can force you to reboot, let alone even doing it for you).

Timo et al, now that nVidia has addressed this bug in updated, stable drivers, what conditions prevent us testing an SRU?

[Dave Vree (hdave)]

This bug is gone in Intrepid. I am running with version 177 of the nvidia driver and my compiz-real process rarely gets about 100MB. It used to take about 3 hours to get to 400MB. No more lock-ups...I am completely thrilled. I have a GE Force Go 7400.

[Petar Velkovski (pvelkovski)]

I'm having the same problem in Ubuntu 9.04 with intel GMA950 graphics. I use intel drivers from xorg-edgers PPA. i am still not sure if it is compiz bug or a intel driver bug or something else. All I know is that after a few hours or mostly a day of usage of my system, the swap drive is getting full (compiz.real uses 1.3GB od virtual memory) and I get noticeable slowdown of the system. Also because I keep firefox open all the time, there appears a problem with font rendering of the new pages I open. Some of the letters become weird, if I zoom in or out the text, some of the letters become readable again, while others become scrambled. Considering the fact that my system is anything but a standard 9.04 installation (because of the now famous Intel graphic driver fiasco) I am not really sure what part of the system to really blame. Is it the kernel (linux kernel 2.6.30rc8 from kernel PPA), is it the mesa drivers or intel driver or whatever that comes from xorg-edgers PPA, or maybe the problem appeared from the compiz upgrade from jaunty-proposed repository, or is it firefox 3.5b4 that I use. All I know is that after a few hours or mostly a day, I have to restart my computer. It's like Bil Gates took over the development of Ubuntu.