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

[Chris Halse Rogers (raof)]

That seems to confirm a leak in GL_EXT_texture_from_pixmap. When running Xgl, Compiz doesn't use the nVidia provided t_f_p, and instead uses Mesa's copy.

I'm retitling the bug with a more appropriate name.

[Jussi Kivilinna (jukivili)]

By monitoring '/proc/<compiz.real-pid>/maps' I noticed that leak seems to source to leaking '/dev/nvidia0' mmaps.

[Sasa Markovic (saxon-eunet)]

Just my two cents:

With everything fully up-to-date, I can only say:

gutsy + nvidia-glx-new + compiz = total disaster

I have an ASUS M2NPV-VM motherboard with an integrated NVidia GeForce 6150GPU. I use the following compiz plugins: Cube, Expo, Rotate Cube, Viewport Switcher, Animations, Water Effect, Windows Decoration, Wobbly Windows, Image loading plugins, Cube Caps, Dbus, Resize info, Video Playback, Application Switcher, Move Window, Place Windows, Scale, Resize Window.

It leaks memory as a rotten barrel and makes my (once beautiful) Ubutnu almost useless. Two or three hours of work and it's dead as a rat. Compiz takes 600-700Mb of 1Gb RAM available, the machine starts swapping and and soon - it's gone.

This was my easisest way to reproduce this bug:

1) Open Thunderbird and Firefox
2) Minimize Thunderbird, Maximize Thunderbird, Minimize Firefox, Maximize Firefox
3) Repeat step 2 and watch how comipz.real leaks memory. You don't need to rotate the cube at all.

After repeating step (2) ten times, memory usage of compiz increased from 275Mb to 433Mb :(

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5504 sasam 15 0 433m 398m 364m S 1.3 40.8 0:37.62 compiz.real

IMHO, this is a *critical* issue: gutsy, nvidia nad compiz are common on many ubuntu installations and god knows how many users will encounter this problem as soon as they upgrade to gutsy.

[beniwtv (beniwtv-deactivatedaccount)]

I'm with Sasa on this.

This issue is *really* critical. Is this already known upstream?

Also, any ubuntu devs to comment, and confirm this bug?

So far, there are two soluctions wich work for me right now:

1. Don't use Compiz. You can do this by disabling it in the appearance applet.
2. Issue a "compiz --replace" once in a while, to clean up the memory

I hope this gets fixed soon :(

[Sasa Markovic (saxon-eunet)]

I just cannot believe that this bug is almost three weeks old without a solution on the horizon?!

It affects mainstream PCs, all of them with Ubuntu flagship product. Isn't it enough to treat this issue as critical ('blocker' being a more appropriate word)?

If Gutsy had been my first expereince with Ubuntu, I would have trashed it after a few hours. But Feisty was so cute, so I'll give Ubuntu one more chance.

(I had to restart Ubuntu since my lasy post - that's why I'm so p*ssed off).

[klerfayt (klerfayt-deactivatedaccount)]

How fast this bug is fixed depends entirely on the actions/will of nVidia
company <-- to give you an example --> it took them more than a year to fix
"black window bug" :-)

On 10/25/07, Sasa Markovic <email address hidden> wrote:
>
> I just cannot believe that this bug is almost three weeks old without a
> solution on the horizon?!
>
> It affects mainstream PCs, all of them with Ubuntu flagship product.
> Isn't it enough to treat this issue as critical ('blocker' being a more
> appropriate word)?
>
> If Gutsy had been my first expereince with Ubuntu, I would have trashed
> it after a few hours. But Feisty was so cute, so I'll give Ubuntu one
> more chance.
>
> (I had to restart Ubuntu since my lasy post - that's why I'm so p*ssed
> off).
>
> --
> 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.
>

[Chris Halse Rogers (raof)]

Here are 3 possible workarounds:
1) Install the xserver-xgl package (sudo aptitude install xserver-xgl, will expose bugs in Wine)
2) Install the nvidia-glx drivers, rather than the nvidia-glx-new drivers (sudo aptitude install nvidia-glx, may have to remove the /lib/linux-restricted-modules/.nvidia_new_installed file)
3) Don't use compiz. (System->Preferences->Appearance->Visual Effects->None)

Annoying as this bug is, it appears to be a bug in the *restricted* nVidia drivers. That means that we have *absolutely* no way of fixing it. This is why the Restricted Drivers manager has a big block of text saying essentially "we can't help you with these, you're on your own". If you have to be annoyed at someone, be annoyed at nVidia.

nVidia has been alerted to this bug. «http://www.nvnews.net/vbulletin/showthread.php?p=1420886#post1420886». There's pretty much nothing more we can do.

[klerfayt (klerfayt-deactivatedaccount)]

How about disabling compiz by default on turbocache cards? (or this memory
leak is random?)

2007/10/25, Chris Halse Rogers <email address hidden>:
>
> Here are 3 possible workarounds:
> 1) Install the xserver-xgl package (sudo aptitude install xserver-xgl,
> will expose bugs in Wine)
> 2) Install the nvidia-glx drivers, rather than the nvidia-glx-new drivers
> (sudo aptitude install nvidia-glx, may have to remove the
> /lib/linux-restricted-modules/.nvidia_new_installed file)
> 3) Don't use compiz. (System->Preferences->Appearance->Visual
> Effects->None)
>
> Annoying as this bug is, it appears to be a bug in the *restricted*
> nVidia drivers. That means that we have *absolutely* no way of fixing
> it. This is why the Restricted Drivers manager has a big block of text
> saying essentially "we can't help you with these, you're on your own".
> If you have to be annoyed at someone, be annoyed at nVidia.
>
> nVidia has been alerted to this bug.
> «http://www.nvnews.net/vbulletin/showthread.php?p=1420886#post1420886».
> There's pretty much nothing more we can do.
>
> --
> 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)]

Another workaround is to do "compiz --restart" when the memory use gets extreme. Window positions are retained.

[Sasa Markovic (saxon-eunet)]

Murat, you probably mean "compiz --replace"? It does not work on my machine, either (compiz restarts, but system freezes, I can hardly reboot it). I can recommend Chris' third solution: turn off compiz completely and wait for a proper nvidia driver.

[Matt Price (matt-price)]

On Thu, 2007-10-25 at 09:09 +0000, Chris Halse Rogers wrote:
> Here are 3 possible workarounds:
> 1) Install the xserver-xgl package (sudo aptitude install xserver-xgl, will expose bugs in Wine)
> 2) Install the nvidia-glx drivers, rather than the nvidia-glx-new drivers (sudo aptitude install nvidia-glx, may have to remove the /lib/linux-restricted-modules/.nvidia_new_installed file)
> 3) Don't use compiz. (System->Preferences->Appearance->Visual Effects->None)
>
confirming that nvidia-glx seems to work on my dell d820 with geforce go
7400. For some reason I thought that nvidia-glx-new was required, not
just recommended. Anyone know whether this works for all cards? This
bug affects enough people that this information should probably go on a
wiki somewhere, which I'm happy to do, but don't want to provide any
false information.

Are there other disadvantages to installing xgl? I remember that when i
tried it earlier it seemed somewhat daunting.

> Annoying as this bug is, it appears to be a bug in the *restricted*
> nVidia drivers. That means that we have *absolutely* no way of fixing
> it. This is why the Restricted Drivers manager has a big block of text
> saying essentially "we can't help you with these, you're on your own".
> If you have to be annoyed at someone, be annoyed at nVidia.
>
absolutely. and not for their response to this bug, which has been ok,
but for maintaining the stupid closed-source policy -- not the fault of
their devs either!

matt

> nVidia has been alerted to this bug.
> «http://www.nvnews.net/vbulletin/showthread.php?p=1420886#post1420886».
> There's pretty much nothing more we can do.
>
--
Matt Price
<email address hidden>

[kikvors (kikvors)]

"1) Install the xserver-xgl package (sudo aptitude install xserver-xgl, will expose bugs in Wine)"

That one works for me so far. No major memory leaks yet. I did not mess with the existing nvidia driver and all seems to be fine.

[klerfayt (klerfayt-deactivatedaccount)]

with xgl fonts loose subpixel hinting?

[Murat Gunes (mgunes)]

Sasa, I didn't mean "compiz --replace"; but "compiz --restart" doesn't seem to be documented anywhere, although effectively what it does is no different than "compiz --gweobrjgo4f" or just "compiz"; it just restarts Compiz. My point is that restarting Compiz is an (obvious) workaround.

[Matt Price (matt-price)]

On Thu, 2007-10-25 at 16:01 +0000, Murat Güneş wrote:
> Sasa, I didn't mean "compiz --replace"; but "compiz --restart" doesn't
> seem to be documented anywhere, although effectively what it does is no
> different than "compiz --gweobrjgo4f" or just "compiz"; it just restarts
> Compiz. My point is that restarting Compiz is an (obvious) workaround.
>

though it's not always effective -- my experience has been that if
leave the computer on & go away, it can be completely unresponsive when
i return, so that i can't even type such a simple command. i suppose
you could map it to an acpi event or something.

matt

--
Matt Price
<email address hidden>

[Ramesh Dharan (rrdharan)]

Matt, I fail to see how this is strictly NVIDIA's fault. Many of the people who have commented on this bug (including myself) had working Compiz setups in Feisty, and they have now regressed to an unusable state in Gutsy.

I was running the exact same NVIDIA driver (100.14.19) in Feisty as I am in Gutsy. Compiz worked in Feisty, Compiz blows in Gutsy. To me, that's a regression on the Ubuntu/Compiz side.

The black window bug had a workaround: compiz --use-copy. Though people didn't seem to be aware of it.

[Ramesh Dharan (rrdharan)]

Does the Xgl X server *still* not support XKB? That was a blocker for me in the past (plus a source of frustration - why the heck would you want XKB in your regular X server but not Xgl?!).

I believe nvidia-glx-new *is* required for some cards, including (I believe) my NVS 285 Quadro. I tried nvidia-glx instead but the stupid lrm-video script wouldn't let the module actually load and refused to tell me what was going on; I didn't bother to track it down. I'll give it a shot again.

[Jussi Kivilinna (jukivili)]

I solved my massive memory leak (compiz.real > 800MiB after few hours) simply by increasing gpu memory from bios from 64mb to 256mb. I have 6100 integrated graphics.

This way I can keep compiz.real memory at less than 40MiB after full day of working but I don't think the underlying bug but only hides it.

[Matt Price (matt-price)]

On Thu, 2007-10-25 at 17:26 +0000, Ramesh Dharan wrote:
> Matt, I fail to see how this is strictly NVIDIA's fault. Many of the
> people who have commented on this bug (including myself) had working
> Compiz setups in Feisty, and they have now regressed to an unusable
> state in Gutsy.
>
> I was running the exact same NVIDIA driver (100.14.19) in Feisty as I am
> in Gutsy. Compiz worked in Feisty, Compiz blows in Gutsy. To me, that's
> a regression on the Ubuntu/Compiz side.
>
Ramesh, I think you're the first person to report that scenario. the
nvidia dev who responded to my bug report says he can reproduce the
scenario on his gentoo box, though... not sure why i think this matters.
anyway, there were reports here earlier that the /proc filesystem
reveals the memory leak is in nvidia...

matt

> The black window bug had a workaround: compiz --use-copy. Though people
> didn't seem to be aware of it.
>
--
Matt Price
<email address hidden>

[Chris Halse Rogers (raof)]

"compiz --use-copy" has never worked with any official version of compiz (either from upstream, or the Ubuntu repositories). The copy-mode-rendering path was patched in to Trevino's compiz packages. If you were using Trevino's packages in Feisty and using this option, then you obviously won't see this nvidia bug - like Xgl, --use-copy makes compiz not use the nVidia provided GL_EXT_texture_from_pixmap.

[Ramesh Dharan (rrdharan)]

Ahah!

That explains a lot.

Thanks, Chris. Now if only I could get Trevino's package to work in Gutsy.

[jimmclaughlin (jomclaughlin)]

Confirming that rolling back from nvidia-glx-new to nvidia-glx
eliminates the memory leak.

best,
jim

On 10/25/07, Chris Halse Rogers <email address hidden> wrote:
> "compiz --use-copy" has never worked with any official version of compiz
> (either from upstream, or the Ubuntu repositories). The copy-mode-
> rendering path was patched in to Trevino's compiz packages. If you were
> using Trevino's packages in Feisty and using this option, then you
> obviously won't see this nvidia bug - like Xgl, --use-copy makes compiz
> not use the nVidia provided GL_EXT_texture_from_pixmap.
>

[Sasa Markovic (saxon-eunet)]

I must agree with Ramesh...

My (and probably his) frustration comes from the fact that I installed Gutsy in a standard way: no hacks, no dirty tricks, just a few clicks to upgrade from Feisty, everything by the book. With a mainstream machine and a mainstream graphics card I expected smooth transition. It looked so until I found out that I had to restart machine on regular basis just to keep it running.

That's my experience. And that experience is, obviously, shared by many others. Not everyone is able to draw a division line between nvidia drivers, compiz and Ubuntu, to read memory consumption of compiz.real process or to play with install-this-try-that approach. People say: "I use Ubuntu", not "I use Ubuntu with a restricted video driver which needs fixing and I'll be patient". Such people (and they are majority) will say that Gutsy just does not work. If that is their first experience with Ubuntu, disappointment is inevitable.

From the overall point of view It does not matter if this problem belongs to nvidia or compiz or Ubuntu. In the end it might turn out that the planets of the Solar systems are improperly aligned and all we can do is to wait until Neptune moves a bit.

I just want to say that this issue is critical to many and needs much more publicity and attention than just a bug tracker page with a (very) cryptic name.

[Sasa Markovic (saxon-eunet)]

I do apologize for frequent posting, but it looks like Evilspy's solution is *REAL* (kudos to him). It's probably the simplest possible workaround available right now (apart from eliminating compiz entirely). At least, it works for me as well.

ASUS M2NPV-VM motherboard with NVidia GeForce 6150 GPU:

1) enter your bios settings
2) go to Advanced/Chipset/Frame Buffer Size
3) default is 64M, increase to 256M
4) reboot
5) play with your cube, windows & effects and monitor memory usage of compiz.real

Prior to this modification I managed to exaust 1Gb of memory in 5 minutes just by playing with windows. Now compiz is almost stuck at 37/38Mb and, trust me, I have played with a lot of windows and made dozens of cube rotations.

I have just decreased frame buffer size from 256M to 128M in order to spare some RAM for OS and it looks promising so far: still at 38Mb.

P.S. I don't have a slightest idea what 'frame buffer size' really mean

[beniwtv (beniwtv-deactivatedaccount)]

Obviously this is only a solution if our BIOS has these settings.

On my HP laptop there's no such settings in the BIOS. In fact, the BIOS has only 3 settings to change :(

Argh....

[Mike Angelo (mikeangelo)]

I was experiencing this problem in a clean and standard install of Gusty (nvidia-glx-new driver and Normal Visual Effects). I agree with others who said this is a critical bug. On one hand, the hardware is very common (in fact, I have the impression that nVidia is generally the "recommended" graphics board for Linux/Unix users), on the other hand, the software environment is the default install of Gutsy.

My motherboard is a Asus M2NPV-VM with an onboard nVidia GeForce 6150. The memory usage of compiz.real would rise in an uncontrolled fashion making the system unusable after a while (a few hours).

Following evilspy tip I increased the Frame Buffer Size from 32 MB do 128 MB in the BIOS and I no longer experience any problem whatsoever. compiz.real memory usage remains under 30 MB (it would previous go over 700 MB). I hope that while we wait for a fix from nVidia this workaround can be effective for more people (probably only those with integrated graphics cards)...

[Sasa Markovic (saxon-eunet)]

I can now confirm Mike's findings: frame buffer of 128Mb is good enough for Firefox/Thunderbird/Pidgin/Terminal/Video type of computer usage (plus a number of special effects). In two and a half hours of regular work and playing, compiz memory usage increased from modest 38Mb to 41Mb.

A number of people will benefit from this, I think.

[cuby (cuby)]

I have a pci express card from nvidia with more than 128MB and I still have this problem.
Can anyone explain this?

[klerfayt (klerfayt-deactivatedaccount)]

You should ask this from nvidia company due to the closed source drivers; if
it helps then I got pci express geforce go 6200 turbocache card with 128MB
(16MB real, rest is taken from ram) and suffer memory leak also...

2007/10/26, cuby <email address hidden>:
>
> I have a pci express card from nvidia with more than 128MB and I still
> have this problem.
> Can anyone explain this?
>
> --
> 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.
>

[cuby (cuby)]

You are correct klerfayt.

>You should ask this from nvidia company due to the closed source drivers; if
>it helps then I got pci express geforce go 6200 turbocache card with 128MB
>(16MB real, rest is taken from ram) and suffer memory leak also...

Another strange thing happened today.
The bug vanished from my system, and I don't know why. Today I've donne:

                     sudo nvidia-settings
to add some good refresh rate, because I've made the upgrade from feisty and it got a little messed up. I send my current xconf.org as attachment... By the way it is a mess because of the new screen and graphics manager.

Instated avant window manager (didn't like it). See:
http://ubuntuforums.org/showthread.php?t=385981&highlight=avant+how+to

[cuby (cuby)]

About last post... Sorry.
The problem is still there, but somehow it's progression is slower.
I've been opening and closing programs like a mad for 20 minutes (to further test) and the resident memory climbed to 155MB and the virtual to 190MB, from several hundreds. I have 1GB.
The memory consumption seems to accelerate with time, hence my initial optimism.

[Chris Halse Rogers (raof)]

As far as I can tell, you will see this bug on any nVidia card with the nvidia-glx-new drivers, but only once you've exhausted the onboard texture memory. So I need to open a *lot* of windows on my 512Mb card before it starts leaking, but it still does. With 64mb of memory, you'll hit the limit much faster, but now instead of seeing black windows, the texture memory for that window will get added to compiz.real's memory space, and won't be released.

So, having enough more memory will greatly reduce the likelyhood that you trigger this bug, but cannot eliminate it entirely.

[Märt Suga (mart-suga)]

I can confirm that.
I have the same problem with nVidia drivers (G72M [Quadro NVS 110M/GeForce Go 7300] on my Dell Latitude D620). With my 1GB ram I run out of memory in about 15 minutes! If I swap "Normal" visual effects to "None", memory usage will drop dramatically (from 90% to 40%). But when I switch visual effects back to normal, memory usage does not leap at all. If this is not a memory leak, then memory leaks do not exist.

[kaltsoplyn (gkatsop)]

Hello, new to launchpad and ubuntu in general, so bear with me if what I say is completely silly
Anyway I experience the same bug (fresh Gutsy install / Toshiba laptop Nvidia Go5200 with nvidia drivers)
I tried "compiz --replace" and well, it works some times but not always.
However I also tried

"compiz --replace --indirect-rendering"

to get rid of the infamous nvidia black screens and it seems to have helped with this bug also:
after 3-4 hours compiz.real stays at about 15 Mb of Ram(!!!). That's a dream comparing to what happened before.
I know that indirect rendering drops the load on the processor but I haven't noticed any particular delay or excessive CPU usage.

[Anton Veretenenko (anton.veretenenko)]

Confirm on Sony Vaio FS415 laptop (GeForce Go6400), leaks for 900+mb by some hours.
Using nvidia-glx-new, tryed nvidia-glx but it fails while loading driver.

[klerfayt (klerfayt-deactivatedaccount)]

by the way - what's the normal usage of ram for Compiz in the beginning?
Does it go straight to 60MB or stays around 16MB?

2007/10/30, kaltsoplyn <email address hidden>:
>
> Hello, new to launchpad and ubuntu in general, so bear with me if what I
> say is completely silly
> Anyway I experience the same bug (fresh Gutsy install / Toshiba laptop
> Nvidia Go5200 with nvidia drivers)
> I tried "compiz --replace" and well, it works some times but not always.
> However I also tried
>
> "compiz --replace --indirect-rendering"
>
> to get rid of the infamous nvidia black screens and it seems to have
> helped with this bug also:
> after 3-4 hours compiz.real stays at about 15 Mb of Ram(!!!). That's a
> dream comparing to what happened before.
> I know that indirect rendering drops the load on the processor but I
> haven't noticed any particular delay or excessive CPU usage.
>
> --
> 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.
>

[kaltsoplyn (gkatsop)]

@klerfayt: it began at around 35Mb and it climbed as time went by.
I never saw a number larger than ~100Mb but then again I never let it run long enough without a "compiz --replace" or sth.
I only have 512Mb and a lot of things running, so when memory leaks my laptop quickly becomes unusable.

[klerfayt (klerfayt-deactivatedaccount)]

it's just that then I installed Ubuntu on other machine I saw also only 16MB used at start and was surprised - because here it uses 60MB immediately at start

[kaltsoplyn (gkatsop)]

I guess that on the other machine there is no hardware graphics acceleration, so "--indirect-rendering" is on by default.
hmmm or vice versa :)
or maybe one machine does not have an nvidia chip, and thus no nvidia driver, which seems to be the weak link of the whole situation.
But anyhow 60Mb at start-up seem a lot.

[Chris McCauley (chris-avondalepark)]

Hi all,

I've switched to an Inspiron 1720 which has an 8600M GT chipset -
previously I had been using an Inspiron 8600 with a 64Mb GeForce 5200.
Compiz.real is behaving itself so I guess the problem is related to the
amount of video memory available. I'm using a release version of Gutsy
on both machines and doing the same set of development activities on
both. I guess testing is happening on relatively recent machines.

Chris

[Anton Veretenenko (anton.veretenenko)]

I have try open many windows on my desktop with GeForce FX5600 (128mb) and compiz there eats memory too. Drivers version are the same as on laptop.

[DasFx (r-launchpad-dasfx-com)]

As Kaltsoplyn stated before, enabling indirect rendering gets rid of the leaking !!!
I enabled it via the compiz-icon and the usage immediately shrunk back to only 25MB and it stays stable.

btw,
The leaking only happens on my dell latitude d620 , which has an nvidia card with 128MB of video, and not on my desktop with a 256MB videocard.
Enabling indirect rendering also took a away the black-window bug in the past on my notebook.

So we have the same workaround again..seems like the leaking and the BWB is somehow related

[Chris Halse Rogers (raof)]

Yes, see my comment above: <https://bugs.edge.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/151168/comments/72>

Previously, when the card ran out of video memory for window textures, you'd get all-black windows instead of the proper texture (the BWB). Using --indirect-rendering made it easier for the drivers to do this correctly (but you could still get black windows if you tried hard enough).

With the nvidia-glx-new drivers, they've done work to fix the BWB. Now, when you would normally get a black window, instead the memory for that window is leaked into the compiz.real process. And if you try *really* hard, you can still get black windows.

So, anything that used to reduce the incidence of black windows (more video memory, --indirect-rendering) will *reduce* (but not eliminate) the incidence of this bug.

It's probably not worth commenting on this bug anymore. We're pretty sure what's causing it, how it's triggered, what it affects, and that we'll need to wait for nVidia to fix it. More "me too" comments almost certainly won't add any useful new information.

[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.