Bug 7106 - XFree86 memory leak
Summary: XFree86 memory leak
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-18 17:28 UTC by mikepery
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-14 17:36:35 UTC

Attachments (Terms of Use)

Description mikepery 1999-11-18 17:28:48 UTC
XFree86 has a memory leak somewhere. Back in Redhat 6.0, I could run X for
weeks on end without any noticeable side effects (I did have the latest
updated rpms of XFree86 - 3.3.5-1.6.0). I just recently installed RH 6.1,
and now after only a few days of X uptime, it balloons into over 90 megs of
usage according to top. I just killed the 90 meg X, but I do have 2 other
sessions running on my machine, here are the top readouts:
 2965 root       0   0 32552  20M   428 S       0  0.0 16.3   0:17 X
 2580 root       0   0 15536  11M  1316 S       0  0.0  9.1 207:41 X
 6811 root       6   0  9380 9380  1972 S       0  0.3  7.3   0:13 X

The last one (9.3 megs) was started 15 minutes ago. Pid 2965 is about 18
hours old. I had a 2 day old one that I just killed that was over 90 megs.
The middle one has been idle most of the time running xlock, so I think it
has to to with actual usage. (The 90 meg one was mine, I'm the primary user
of the machine).

Comment 1 mikepery 1999-11-18 17:34:59 UTC
I just checked my roommates 6.0 box, and his week old X session is 45 megs (a
fresh X session on his box is 12 megs). So I guess there was still a memory leak
in 6.0's XFree, I just didn't notice it cause back then I was the only user of
the machine. btw: we are both running the SVGA servers. I'm going to post this
to the XF86 dev team as well.

Comment 2 mikepery 1999-11-22 01:00:59 UTC
I did some more experiments, and it appears the xlock IS the culprit (I was
looking at the wrong session). 8 hours of xlock will shoot the memory usage of a
session past 50 megs. I contacted the XFree team already, but they seemed
skeptic at first, and haven't gotten back to me since. Perhaps the leak has
something to do with writing to the root window?

Comment 3 Preston Brown 2000-01-14 17:36:59 UTC
X caches pixmaps.  If you use a graphics intensive application, X will increase
largely in size.

This is a design issue, but not really a bug we can fix.

Comment 4 Keith Baker 2000-02-29 19:56:59 UTC
While this is a "design issue" it has caused my machine to become unusable many
times.  It seems fairly unacceptable that I have to restart X (assuming I catch
its balloning quickly enough and don't have to restart the entire machine --
with enough swap it makes a noticeable slowdown soon enough...  with to little
swap my machine becomes unrecoverable to quickly to catch)...  Restarting the
computer or X is UNACCEPTABLE and I think this should be taken off of a "won't
fix" problem because fixing it is necisary to maintain a usable system.  Maybe
their is a bug in the pixmap caching system that it caches to many pixmaps and
keeps eating up memory.  A 100 Meg cache on a 128 meg machine is rediculas!
Cache is supposed to speed things up, not slow them down.  I have also noticed
that I never had this problem with 6.0 or any of the 5.x series that I ran.  It
seems like their is a problem clearing the cache at the approprite time.

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