Bug 75270 - Incredibly bad memory leaks in gnome-terminal, causing entire system to lock up when RAM/swap maxed
Summary: Incredibly bad memory leaks in gnome-terminal, causing entire system to lock ...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vte   
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL: http://strike.homelinux.org/~ddipaolo...
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-06 17:57 UTC by Need Real Name
Modified: 2007-04-18 16:47 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-04 05:39:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
with nolinear enabled (3.34 MB, text/plain)
2002-10-30 22:05 UTC, Need Real Name
no flags Details
nolinear removed and X restarted (709.72 KB, text/plain)
2002-10-30 22:06 UTC, Need Real Name
no flags Details

Description Need Real Name 2002-10-06 17:57:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913

Description of problem:
There's one major caveat to all of this, and that caveat is that I've done a tad
bit of modification to the system that MAY have caused this bug, but seeing as
how I don't see any feasible way that it would have, I am submitting this bug
report.  First, however, the modifications I have made:

1. Added a new service to startup, which I called "vidcard".  Basically, it runs
a utility to fix problems with my video card, an Intel i830M.  The source code
for this utility can be seen here:  http://www.jongans.com/i830-16bit.C  (the
IO_BASE_ADDR was modified to match my hardware, however).  I just dropped the
compiled binary in /etc/init.d and then symlinked it in /etc/rc.d/rc5.d as
2. Modified X RPMs.  Basically, I just added one patch to the SOURCES directory,
and plunked in the patch into the specfile as number 9999 and built with
"rpmbuild -bb XFree86.spec".  Thankfully, the patch applied cleanly :)  The
patch can be seen at
http://strike.homelinux.org/~ddipaolo/misc/1mb-stolen-fix.diff for reference. 
Then, of course, I simply installed the XFree86 rpms with "rpm -Uvh

Now, onto a bit more in depth bug description.  The bug is almost definitely
with gnome-terminal (or maybe with one of its libs, like .. libzvt(?)), because
I've tried similar things in xterm with no problem.  Simply put, gnome-terminal
leaks memory like a sieve on my system.  Within a matter of minutes, it
eventually overtakes ALL available RAM (256MB each RAM, swap) on the system and
causes horrible disk thrashing rendering the system completely unusable (i.e. I
can't even switch to a virtual term and login as root).  I've got some cute
screenshots of the whole progression here -
http://strike.homelinux.org/~ddipaolo/screenshots/gnome-terminal  (referenced in
the URL field as well).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Load up gnome-terminal (any which way you like)
2. Do .. anything in it, anything at all.  My favorite thing to do is "for i in
`seq 999`; do sleep 1; echo "i = $i"; done, and watch gnome-system-monitor with
a bucket of popcorn at hand.
3. Eat popcorn, watch memory usage creep up at around 1MB/s
4. Hit the Big Red Button (TM) when memory gets maxed out and system becomes
unresponsive due to disk thrashing.

Actual Results:  Step 4 in reproducing it sums it up:

"4. Hit the Big Red Button (TM) when memory gets maxed out and system becomes
unresponsive due to disk thrashing."

Expected Results:  Er, the memory usage should hit a ceiling and stop there ...
I'm not doing anything that requires more memory, past a bit of initial loading.
 xterm does this with never making a footprint of over 2.6MB

Additional info:
That User Agent field is kinda bogus .. this isn't the machine with the problem.

Comment 1 Miloslav Trmac 2002-10-06 18:25:16 UTC
For me, runing 'seq 999999' has absolutely no effect on memory consumption.

gnome-terminal-2.0.1-5, vte-0.8.19-1

Comment 2 Havoc Pennington 2002-10-06 19:09:04 UTC
This is awfully strange, we have several "leaks memory instantly at the drop of
a hat" reports, but then it seems to work OK for most people.
There's some detail of how to trigger it that we're missing.

Comment 3 Need Real Name 2002-10-06 20:14:45 UTC
Well, I'm willing to cooperate (read: perform test scenarios) as much as you
like, seeing as how I really want gnome-terminal as something I can use for more
than 3 minutes. :)  Feel free to contact me directly if you don't want to
clutter up the bugzilla logs.  I can also provide more hardware info if you
need, but you have all the relevant software info, with maybe a few exceptions.
 Basically, this was experienced on a vanilla RedHat 8.0 install (checked
install media with both md5sum and during the install).  Actually, it was
experienced with two installations on the same machine (this bug aggravated me
to the point of desperately trying to reinstall instead of seeking further
problems).  Also, I ran the memory profiler on it and saved the leak info and
memprof info if you would like me to attach it here.  I don't know how useful it
will be, considering I didn't really get to use the terminal ... it didn't seem
to be the same problem.  But, I can post the data if you like.

Comment 4 Need Real Name 2002-10-08 16:28:02 UTC
I am also seeing this problem. I left gnome-terminal running overnight and when
I came this morning, my hard drive was thrashing and reported about 400M of swap
space in use! According to top, gnome-terminal was using about 350 or so megs.
It's averaging about a 1mb/min just sitting there with no activiity. Xterm works

Comment 5 Need Real Name 2002-10-09 21:00:40 UTC
Looks like a potential dupe of:

#74748, #74972, #75211, #75498

Not marking as a duplicate just yet, however.

Comment 6 Nalin Dahyabhai 2002-10-17 22:22:40 UTC
If you run "xdpyinfo", is RENDER one of the listed extensions?

Comment 7 Need Real Name 2002-10-20 17:40:31 UTC
No, no RENDER extension.  The i830M has no RENDER extension support yet, as far
as I know.

Comment 8 Need Real Name 2002-10-29 21:53:28 UTC
I don't think this is an X leak (as mentioned in a related bug), but rather a
leak somewhere in Gnome 2. Today, after about 12 days of use, my system starting
thrashing yet again and the main users of memory were gnome-panel[365Mb] and

I also don't have the RENDER extension.

Comment 9 Need Real Name 2002-10-29 22:00:55 UTC
These are the actual values if anyone cares...

114 #507      15   0  426M  87M  5556 S     1.1 17.4   3:39 gnome-panel
18274 #507      15   0  137M  83M 18596 R    10.9 16.6  70:40 mozilla-bin
 1104 #507      15   0  274M  64M  4252 S     0.9 12.8   4:11 metacity
 1395 root      25   0 65928  64M 28676 S     0.1 12.8   0:55 java
  790 root       5 -10 48228  18M  2676 S <   7.2  3.5  4719m X
  725 xfs       15   0 21432  10M  3160 S     0.0  2.1   0:18 xfs
 7243 #507      15   0 11012  10M  3856 S     0.1  2.0   1:50 emacs
17727 #507      15   0  6496 6000  3772 R     0.1  1.1  21:32 xmms

4:11pm  up 12 days,  3:23,  3 users,  load average: 2.10, 1.95, 1

Comment 10 Need Real Name 2002-10-30 22:05:22 UTC
Created attachment 82785 [details]
with nolinear enabled

Comment 11 Need Real Name 2002-10-30 22:06:15 UTC
Created attachment 82786 [details]
nolinear removed and X restarted

Comment 12 Need Real Name 2002-10-30 22:06:32 UTC
I figured the problem out! It was indeed something withing X that was causing
the leak, specifically Gnome2 would call some render routine inside X. See
attached memprof logs, if you're curious.

I am using the ATI driver (Rage XL) and had probem with a particular Mozilla
theme (modern) getting corrupted, so I was told to set the "nolinear" option in
my X configuration. When I remove this flag, the memory leaks disappear.

Comment 13 Ray Strode [halfline] 2004-11-04 05:39:10 UTC

This bug is quite old and Red Hat no longer maintains the version of
Linux this bug is filed against.  Does this problem persist in Fedora
Core with xorg-x11?  If so, please open a new bug file against the
xorg-x11 component.


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