From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Description of problem:
Whenever start using gnome-terminal it eats memory until oom and it is killed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start gnome-terminal
2. do something it it, i.e. top ot tail /var/log/messages
Actual Results: memory footprint continue to increase until oom
Expected Results: memory footprint should be small and not increase
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
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
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:
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.
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.
I think we'd like to get an errata out in the next month or so, but
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
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 email@example.com 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
*** 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??
# rpm -qa | grep Xft
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
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...