Bug 7106 - XFree86 memory leak
XFree86 memory leak
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Preston Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-18 12:28 EST by mikepery
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-14 12:36:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mikepery 1999-11-18 12:28:48 EST
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 12:34:59 EST
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-21 20:00:59 EST
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 12:36:59 EST
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 14:56:59 EST
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.