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): XFree86-4.3.0-2 How reproducible: Always 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.
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 resources. 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.