Community
Participate
Working Groups
I've only started noticing this recently (possible 3.6 but definitely 3.7). I'm running the latest version of SL. I only use the 64bit Cocoa version, so I'm not sure if the 32 bit version has a similar issue. During general Java development (refactoring, editing, building, etc.) the Mac OS X WindowServer memory usage increases until it consumes large amounts of real memory. Prior to launching Eclipse, it uses about 90MB. After an hour or so, it has consumed over 1GB of real memory at which point my system is pretty much unusable (I only have 3GB). The Quartz Debug Window List shows in excess of 150 windows have been created by Eclipse. Most of these appear to be tooltip popups and context menus (some are just blank rectangles) that were displayed at some point. Since WindowServer is responsible for handling the interaction with the graphics hardware, it appears that the UI is creating Cocoa objects that are not getting released, or something similar. Please let me know if there is any other debugging information I can provide.
I forgot to mention that if I quit out of Eclipse, the WindowServer memory is released almost immediately, so there is very little doubt that Eclipse is responsible for the problem.
Moving to SWT
I see the same. After a bit of work (I'll restart eclipse every day) the WindowServer consumes huge amounts of memory (500-1000MB). Shutting down eclipse free the mem from the WindowServer.
I have also noticed this issue on MacOS 10.5.8 cocoa (32-bit). I also would tend to think this an SWT memory leak.
I have started to notice this in 32-bit Eclipse version, where the dialogs started to look blank after a few hours of regular working. I have seen many OutOfMemory errors in the logs, 64-bit version simply lets the memory grow more, so the outcome is the same: I have to restart sometimes even a few times a day (WindowServer memory usage easily grows to 2GBs).
Also occurs on Lion (10.7.2).
And Elipse 4.2.
Wow! This is a serious bug. Basically, every shell with the SWT.TOOL style bit is leaked. Thanks for the investigation. Fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3ef72dc42513515df553f500b077076464e6abd9
*** Bug 356601 has been marked as a duplicate of this bug. ***
Mike/John, we have to fix this in 3.7.2.
Back ported to 3.7.2 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_7_maintenance&id=52de1f9158541d5fa279cd0ccd60c8a0ef968370
*** Bug 343056 has been marked as a duplicate of this bug. ***
Here are some steps to check the WindowServer memory: 1) Run the ActivityMonitor app 2) Select "All Processes" in the combo just before the search field 3) Select the Process with name: WindowServer Every time a shell is created for any application, the column "Real Mem" should go up. The memory needs to come down when the shells are disposed. Note that the eclipse tooltips for the editor (JavaDoc, etc) are only disposed when the editor is closed.
*** Bug 304857 has been marked as a duplicate of this bug. ***
Created attachment 211703 [details] Stack trace from eclipse crash I've updated Eclipse to have org.eclipse.swt 3.7.2.v3740f and now I'm no longer seeing the blank shell screens, but I've had eclipse completely crash on me several times. Here's one of the error stack traces that were returned. If this is helpful or you'd like other traces, let me know. If I should create a new bug, I'm happy to do that too.
(In reply to comment #15) > Created attachment 211703 [details] > Stack trace from eclipse crash > > I've updated Eclipse to have org.eclipse.swt 3.7.2.v3740f and now I'm no longer > seeing the blank shell screens, but I've had eclipse completely crash on me > several times. Here's one of the error stack traces that were returned. If > this is helpful or you'd like other traces, let me know. If I should create a > new bug, I'm happy to do that too. Please open a separate bug. This stack trace does not seem related with this bug. In the new bug, add info like which version you were running before and what you are doing when the crash happens. From the stack it seems you are swiping the trackpad (right?). Are all the stack traces the same? If not, attach them.
Has this been fixed in 4.2?
Yes, it is fixed in 3.7.2 | 3.8 | 4.2.
*** Bug 360610 has been marked as a duplicate of this bug. ***
