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):
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
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.
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.
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
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.