Bug 76219

I can verify that. The terminal won't release any memory, until all RAM and SWAP
has gone, than it dies, which releases the memory. I experienced this behaviour
on 5 independent RH8.0 PCs. Please patch this soon!

If you run "xdpyinfo", is RENDER one of the listed extensions?

RENDER is not one of the listed extensions for this display.
Here are the extensions listed:
number of extensions:    27
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RECORD
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo

Dido all comments.Redhat 8.  standard Workstation install. Gnome.  Open terminal.
Vi/vim a file.  Work on file for 3 minutes  using j and k keys then
Bam   keyboard/mouse/system lockup.  System reset time.

Memory leak.  init 3.  startx.  Gnome desktop. open command terminal.
then do nothing. walk again. come back in 2 hours.  Screen saver image
frozen  system locked up.  Bug or configuration problems.  If 
configuration problem then Redhat 8 installer causes problem.

This is an Xrender (or Xft?) bug right? We should reassign accordingly.

This bug also appears consistently when running under Xvnc.  To confirm: install the vnc 
package, launch vncserver.  Launch a vnc viewer from another computer, connect to the 
vnc server.  All gnome-terminals opened using this vnc server will have a horrible 
memory leak. To make matters worse, the gnome-terminals act like a multi-threaded 
application, so when the system kills one terminal window,  *ALL* terminal windows die.

(And when launching gnome-terminal as root, you may see a complaint saying "Xlib:  
extenaion "RENDER" missing on display ":1.0".)

I've been encountering the same thing.  It seems to only happen with
gnome-terminal using an anti-aliased font AND using a certain graphics drivers,
i.e. the i845g (intel motherboard with intel graphics) exhibits this problems,
other machines with other drivers (nvidia or matrox) do not seem to.  The really
puzzling thing is that it's gnome-terminal who has the memory leak, not xfs, or
the X.

So it would see the error is actually in gnome-terminal, or possibly in X, I.e.
gnome-terminal is allocating a bitmap, passing it to the x-server, which is
passing it to the hardware driver, and some of the drivers are not freeing the
memory, hrm that doesn't quite explain it.

Here's the xdpyinfo listed extensions on a machine that DOES exhibit the problem:
    BIG-REQUESTS
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    FontCache
    GLX
    LBX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RECORD
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XC-APPGROUP
    XC-MISC
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo

After launching my first gnome-term and running man bash | grep " "
-bash-2.05b# ps -acux | grep gnome-term
sa       31433  0.3 17.3 99788 88140 ?       S    Oct21  11:05 gnome-terminal

Ah, none of our comments have communicated that we do actually know what this
bug is. ;-)

It's an Xft bug; Xft gets X images and doesn't free them again in the fallback 
case when you don't have the render extension. Result, every time the terminal
draws text a big block of pixel data is leaked on the client side.
Not pretty.

I don't know enough of the details to know why it doesn't happen with 
all GTK 2 / Qt 3 apps, but the above is what I'm told the leak was.

Any ideas when this might be resolved?  I'm trying to decide if I should just go
out and get another video card...if RENDER isn't going to be supported on mine
soon and this isn't fixed soon.  BTW, I have an Intel 845GV.
-Thanks!

I think we'd like to get an errata out in the next month or so, but 
can't promise.

Ugh! I can't replace the i830 video hardware on my laptop! Please fix soon!!! :-)

I can verify that the work around is to go into the font preferences and turn
off antialiasing (i.e., choose monochrome). Gnome-terminal stops leaking (but
looks like s**t). Interestingly, the font preview panes in the font preferences
tool are completely blacked out. (I have an i830 video chipset.)

Actually this IS an issue with all GTK2 apps (e.g. gnome-panel is also affected,
since the clock uses text - if left running for several days, gnome-panel will
be consuming about 100M).
It's just that gnome-terminal seems to redraw its entire screen for each and
every change, which leads to the huge leaking (1.5G after about 6 hours of
development work).
In any case, this is such a big issue, that I'm surprised this hasn't been fixed
yet (especially since it sounds like a very trivial fix (properly freeing the
memory in Xft)).

I have also had the same problem as tim.vanholder with gnome-panel, 
as well as gnome-terminal. gnome-terminal just does it much more frequently, 
and much more rapidly. Must be something bigger than just gnome-terminal tho

I am expierencing the leak too.

It seems to happen at all times at runlevel 5, seems like all gtk stuff.

For instance if I continually open and close terminal windows, the memory in use
will continually climb, and I can wait all I want and the memory is never
released... So doing development over a day or two will eventually leak close to
the 1GB of memory that the system has.

Any work on a fix yet?

Test packages at: ftp://people.redhat.com/hp/testing/

Please let me know if these are good to be released as errata, 
or if they don't solve the problem.

Upgrading Xft to the proposed Xft-2.0-4.i386.rpm works for me.
I've been running test for a while now and memory usage seems to stay reasonable.

bug 73156 is "gnome-terminal leaks memory". Dup..

I upgraded as well, and am not seeing the leak anymore

just tracking to a conclusion

hp's Xft update works for me too.

Xft update WFM

*** Bug 76410 has been marked as a duplicate of this bug. ***

*** Bug 79723 has been marked as a duplicate of this bug. ***

This bug was killing our RedHat boxes.  Have upgraded to Xft-2.0-4.i386.rpm and Xft-devel-2.0-4.i386.rpm from ftp://people.redhat.com/hp/testing and bug seems to be fixed

The Xft-2.0-4.i386.rpm also fixes it for some of our users who were having this
problem when using gnome-terminal via Exceed from Windows.

Just another note; using an Intel i845g graphics card, the memory leak bug bit
me - the newer package seems to have completely resolved the issue now, tho.  (I
can use gnome-terminal without having 1.5G of memory eaten in <5 mins; it hasn't
even gone over 15M of memory, altho that still seems a tad bit ludicrous...).

*** Bug 73156 has been marked as a duplicate of this bug. ***

Bug shows on Intel D845GRG ATX motherboards using the onboard graphics 
controler. The same board with an nvidia card added does not show the problem. 
A quick workround is to use xterm though the machine still needs to be 
restarted once or twice a day. Upgrading to Xft-2.0-4.i386.rpm appears to cure 
the problem.

*** Bug 84444 has been marked as a duplicate of this bug. ***

*** Bug 86485 has been marked as a duplicate of this bug. ***

*** Bug 73226 has been marked as a duplicate of this bug. ***

*** Bug 73332 has been marked as a duplicate of this bug. ***

Xterm and Gnome Terminal still exhibit memory leak behavior after Xft upgrades 
and reboot.  Different bug??

Confirmed:
# rpm -qa | grep Xft
Xft-devel-2.0-4
Xft-2.0-4

RH 8.0 running on a Dell PowerEdge 2600, has all current patches from RHN.  
I'm connecting to it (XDMCP) with a Dell 8200 (845MP chipset) through XWin-32 
5.4 client.  Opening xterm or gnome terminal and running "ls -lR /" will 
consume 100MB within about 60 seconds.  It then continues consuming RAM @ 
1MB/sec roughly (as viewed in top's Mem: summary - but not for the xterm or ls 
process themselves, those remain constant) until interrupted, but exiting from 
the terminals does not free memory.  

(By the way, why is a gnome terminal **SO** much slower and choppy at 
directory listings than xterm?  Xterm is many times faster.  ??)

I've also seen the RENDER extension comment referred to earlier in this bug 
description.

Anyway... had very high hopes when I read the Xft upgrade fixed the issue for 
others.  Not in my case though.  :(  Any other new info on this?  The X Font 
rendering mem leak would explain the ls issue and why it happens in both xterm 
and gnome terminals.  Why didn't the upgrade help me?  Does OS upgrade to RH 
9.0 solve this?

Need resolution badly - this plagues a machine that is soon to be deployed in 
a 24-hr operational environment.  Frequent reboots are *highly* undesireable.

If the xterm isn't consuming the memory, what are you looking at when you say
100M gets leaked?

The total memory usage value in top is just useless because it includes disk
cache buffers; this means it basically never goes down. Run "free" and look at the 
line about "+/- buffers/cache" (yes, this is a major UI bug in top/free)

gnome-terminal is slower in 8 just because it wasn't optimized, it's as fast as
xterm in 9 in simple timings (with xterm using Xft), though it still has a
couple bugs in 9 e.g. it's much slower when running "screen"

Your comment reminded me to close this bug...