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):
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
That User Agent field is kinda bogus .. this isn't the machine with the problem.
For me, runing 'seq 999999' has absolutely no effect on memory consumption.
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.
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.
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
Looks like a potential dupe of:
#74748, #74972, #75211, #75498
Not marking as a duplicate just yet, however.
If you run "xdpyinfo", is RENDER one of the listed extensions?
No, no RENDER extension. The i830M has no RENDER extension support yet, as far
as I know.
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.
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
Created attachment 82785 [details]
with nolinear enabled
Created attachment 82786 [details]
nolinear removed and X restarted
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.
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