Bug 98978 - X server memory leak
Summary: X server memory leak
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-11 09:39 UTC by Radu Radutiu
Modified: 2007-04-18 16:55 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-11 23:17:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Radu Radutiu 2003-07-11 09:39:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Description of problem:
Working with Eclipse will cause the X server to allocate memory that is never freed.
The problem occurs on RH 9, regardless of the version of Eclipse used (2.1,
2.1.1, gtk and motif builds, different jdk's: Sun JDK 1.4.2, Sun JDK 1.4.1_02,
IBM JDK 1.4.1, IBM JDK 1.3.1_05)
Problem reproduced on the following systems:
RH9 ,Inspiron 4000 Ati rage Mobility M3 8mb RAM, Pentium III, 512 Mb RAM - with
"r128" and "vesa" drivers
RH9, Compaq Evo (Intel 82845G/GL [Brookdale-G] integrated graphics chipset,
Pentium IV, 512 RAM), - "i810" driver 
The problem does not occur on RH 8 (Inspiron 4000 with Nvidia graphics) or
Mandrake 9 (Compaq Evo as above)

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

How reproducible:

Steps to Reproduce:
1. Start eclipse 2.1 on a RH 9 machine.
2. Open several large java files and use Show Outline (Ctrl+O) for navigation
(several times)
3. Open top and look at the X server RSS column

Actual Results:  The X server allocates memory proportional with the number of
operations performed. This memory is never freed, even after eclipse is closed.

Expected Results:  The amount of memory allocated by the X server should remain
at a resonable level and this memory should be freed once the app is closed.

Additional info:

When the system starts X RSS size is around 6 MB.
After performing several operations in Eclipse X allocates over 200 Mb.
 2413 root      15   0  206M 195M   732 S     3.9 39.0   3:23   0 X
The memory is never freed and the system starts trashing.

Comment 1 Mike A. Harris 2003-07-11 23:17:11 UTC
Similar problems have been reported by users running Java applications in
the past.  To date, all such problems that have been reported have turned
out to be Java bugs, where java allocates X resources and never frees them.

The problem isn't X memory leaks, but application (Java) X resource leaks,
and since X resources are stored in the X server, this results in the X
server's process increasing in size until the application releases those

This is similar in nature to a memory leak, however reporting the problem
against the X server is similar to reporting a bug against the kernel when
an application has a memory leak.  It's not the kernel's fault, it is the
buggy application.

Please report this problem to your java vendor for them to investigate where
their java implementation is leaking X resources.  They may be able to use
the experimental Xres extension and "restest" application to assist them,
however it is very rudimentary currently and has been known to crash the
X server, so use with caution as it is experimental only and not supported
by Red Hat, but just included for developer convenience.

For true X server memory leaks, which are very very rare, in order to fix
such leaks, we require a very small test case written in C which can trigger
the problem in the X server under a minimal X environment where only the
X server is running with a single client and no desktop or window manager.
To do this, you must run X by typing "X" with an xterm in your .xinitrc, then
run the test case application and trigger the alleged memory leak.  If the
leak is reproduceable, you can report the bug in bugzilla along with full
details and with the small C test application.  For fastest results it should
be reported upstream to XFree86.org so that the entire team of X developers
are aware of the issue, which will expediate investigation and resolution.

If the test case does not reproduce the problem and a test case can't be
produced to illustrate it, it is more likely than not - an application X
resource leakage problem and not an X server bug.  In this case, please
contact the faulty application's upstream vendor or project directly to
report the issue.  In this case, it would be the Java supplier.

Hope this helps.

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