Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 76219 - gnome-terminal memory leak
Summary: gnome-terminal memory leak
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: Xft
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
: 73156 73226 73332 76410 79723 84444 86485 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-18 11:35 UTC by Thomas Svedberg
Modified: 2007-04-18 16:47 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-07-31 23:53:42 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:305 normal SHIPPED_LIVE Fix memory leak in Xft 2003-08-08 04:00:00 UTC

Description Thomas Svedberg 2002-10-18 11:35:30 UTC
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):

How reproducible:

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 

Additional info:

Comment 1 Need Real Name 2002-10-18 15:00:20 UTC
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!

Comment 2 Nalin Dahyabhai 2002-10-18 21:56:29 UTC
If you run "xdpyinfo", is RENDER one of the listed extensions?

Comment 3 Thomas Svedberg 2002-10-19 06:33:53 UTC
RENDER is not one of the listed extensions for this display.
Here are the extensions listed:
number of extensions:    27

Comment 4 Rob Sexmith 2002-10-21 20:20:15 UTC
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.

Comment 5 Havoc Pennington 2002-10-21 21:50:03 UTC
This is an Xrender (or Xft?) bug right? We should reassign accordingly.

Comment 6 Jeff Stearns 2002-10-22 03:40:32 UTC
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".)

Comment 7 bill 2002-10-23 23:02:17 UTC
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:

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

Comment 8 Havoc Pennington 2002-10-24 00:09:43 UTC
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.

Comment 9 Brian Huffman 2002-10-29 18:38:01 UTC
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.

Comment 10 Havoc Pennington 2002-10-30 14:43:08 UTC
I think we'd like to get an errata out in the next month or so, but 
can't promise.

Comment 11 Tim Keitt 2002-10-30 20:46:47 UTC
Ugh! I can't replace the i830 video hardware on my laptop! Please fix soon!!! :-)

Comment 12 Tim Keitt 2002-10-30 20:53:12 UTC
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.)

Comment 13 Need Real Name 2002-11-13 09:07:13 UTC
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)).

Comment 14 Adam C. Greenfield 2002-11-13 14:21:39 UTC
I have also had the same problem as 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

Comment 15 Need Real Name 2002-12-04 18:01:07 UTC
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?

Comment 16 Havoc Pennington 2002-12-04 21:09:24 UTC
Test packages at:

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

Comment 17 Thomas Svedberg 2002-12-05 07:55:37 UTC
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.

Comment 18 R.K.Aa. 2002-12-06 00:29:01 UTC
bug 73156 is "gnome-terminal leaks memory". Dup..

Comment 19 Need Real Name 2002-12-10 16:17:43 UTC
I upgraded as well, and am not seeing the leak anymore

Comment 20 Tim Coote 2002-12-13 14:01:29 UTC
just tracking to a conclusion

Comment 21 Frank Ch. Eigler 2002-12-18 12:26:24 UTC
hp's Xft update works for me too.

Comment 22 Need Real Name 2002-12-31 14:49:58 UTC
Xft update WFM

Comment 23 Owen Taylor 2003-01-07 20:47:50 UTC
*** Bug 76410 has been marked as a duplicate of this bug. ***

Comment 24 Owen Taylor 2003-01-07 20:48:33 UTC
*** Bug 79723 has been marked as a duplicate of this bug. ***

Comment 25 Gavin Timmins 2003-01-08 12:23:59 UTC
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 and bug seems to be fixed

Comment 26 Panu Matilainen 2003-01-14 11:37:59 UTC
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.

Comment 27 Sean Middleditch 2003-02-04 19:36:03 UTC
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...).

Comment 28 Nalin Dahyabhai 2003-02-08 00:14:38 UTC
*** Bug 73156 has been marked as a duplicate of this bug. ***

Comment 29 Andy Mackintosh 2003-02-13 10:05:21 UTC
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.

Comment 30 Havoc Pennington 2003-02-17 16:19:46 UTC
*** Bug 84444 has been marked as a duplicate of this bug. ***

Comment 31 Havoc Pennington 2003-03-24 03:34:26 UTC
*** Bug 86485 has been marked as a duplicate of this bug. ***

Comment 32 Nalin Dahyabhai 2003-05-15 20:28:53 UTC
*** Bug 73226 has been marked as a duplicate of this bug. ***

Comment 33 Nalin Dahyabhai 2003-05-30 23:08:41 UTC
*** Bug 73332 has been marked as a duplicate of this bug. ***

Comment 34 Jason 2003-07-31 23:05:11 UTC
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.

Comment 35 Havoc Pennington 2003-07-31 23:53:42 UTC
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...

Note You need to log in before you can comment on or make changes to this bug.