Community
Participate
Working Groups
I have a bit of evidence for this from bug 193761 (see comment#22, comment#19 and my earlier comments) but nothing definitive other than the following ideas for helping identifying this problem. Only reproduced with the Sun VM. 1) It appears that there may be some sharing of handles between Java VMs that's going on, because launching a runtime workspace can cause the host workspace to run out of handles and die. Launching in a non-Sun VM appears to be a work-around for this. 2) Both myself and Rob Elves work self-hosted in runtime workbenches. Sometimes our runtime workbench will now die around the 5000 handle mark, which was never the case on XP. Fyi, the only way we reach 5000 is by having dozens of browser editors and task editors open, which is typical usage but is a reasonable thing to do. 3) If I run Adobe Photoshop at the same time as Eclipse, my runtime workbench will run out of handles much more quickly. I have no idea how this makes any sense beyond Photoshop potentially being a handle hog. Marking as major because I think that this could be worth investigating if it is happening to others, and because Eclipse dies in the scenario where there are no more handles. However, if (1) holds, I assume that users who only run a single workbench will not be nearly as likely to see this.
Another non-reproducible handle problem is recorded as bug 188456 ("Sometimes Eclipse allocates lots of handles (extra 10K of semaphores)"). As a point of curiosity, the number of *GDI* handles on a Windows machine is typically limited to 10K per process; see HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Windows NT/ CurrentVersion / Windows -> GDIProcessHandleQuota. However, system-wide, the max number of GDI handles seems to be about 32K. Meaning that if you have applications X, Y, and Z using up their 10K of handles, few handles will remain available system-wide. This might explain the effect of running Photoshop and Illustrator you described in the original bug 193761 comment 22.
We had Shawn Minto (now CC'd) investigate this when trying to figure out what's going on with the handle counts. I believe that his last assessment was that Sempahore handles can climb as high as they want and they won't cause of of handles errors. Those semaphore counts seemed to be the result of synchronize blocks not being destroyed, and we only saw that happen on Sun 1.5 VMs. Just did a quick check and the semaphore count appears normal on Shawn's Sun 1.6 VM. Very interesting point about my hitting the max number of GDI handles, that sounds like it could be right. I now recall that Photoshop was not redrawing itself properly either, which does seem to imply a system-wide max. It is interesting that I only started hitting this max on Vista (not XP). Could be that the fancier Microsoft Office 2007 and other vista programs impose a higher handle load (Outlook comes close to 4000).
Just as a note, my Oulook 2003 only uses 700 handles.
Wow, mine Outlook currently 3476. I wonder if the reason is all the new color gradients that Microsoft Office 2007 uses. My iTunes, with it's own gradients, is 2000 handles. If this is the reason, I guess that the high-order bit is that having several modern applications (i.e. heavy use of gradients) can mean that running a couple of workbenches at 5000 handles a pop can hit the OS max. Oleg: I think that this "hitting global max" theory could explain my cases 1-3 in the description. (1) is still a bit weird and I wonder if all the VMs for a single java.exe share a 10000 max on Vista (this is indeed my GDIProcessHandleQuota setting).
The theory that what we're seeing is the global max being hit appears correct, so updating summary. Mylyn is putting in some solutions in order to avoid handle bloat as much as possible (e.g. bug 206568). However, this problem will likely be an ongoing concern because it appears to be too easy to hit the global max. Also, if there is indeed sharing of handles between VMs, all it will take is an Eclipse IDE and a handful RCP apps to hit the process max.
If we (Eclipse, SWT, RCP apps) are leaking, we should fix it. There is some discussion going on in bug 212345 about tracking resource and finding leaks. I'm not it's an SWT problem if programs use too many resources, but I am interested in knowing exactly is going on. If you (Mik) can share with me some of the details about hitting the limit and hold my hand a bit to create reproducable (simpler) cases, there might be something I can do. Can you confirm 100% that it is a Sun VM thing?
Steve: Sorry for the slow reply. No, I can't confirm 100% that this is a Sun VM thing, and as per the comments above my current suspicion is that the problem is not excessive use of handles by the Sun VM, but hitting Windows global handle max. I've changed my configuration to use jrockit-27.5.0 and will report back if I run out of handles the same way. I have still been running out of handles whenever I keep Adobe Photoshop and/or Illustrator running, in which case I always seem to run out below the 5,000 handle mark for javaw.exe (note that I work in a runtime workspace).
Fyi, I haven't yet run out of handles when running with jrockit-27.5.0, because according to the Windows Task Manager appears to use 1/2 the handles of the Sun VM (launches with 800 instead of 1800, haven't seen it go over 2500 during use whereas the JDK 6 Update 6 was getting close to 5000).
(In reply to comment #8) I can't seem to get over 2500 or so handles with jrockit-27.5.0 and as such haven't once triggered the handle max. Since I've never heard IBM'ers complain about this problem either, I assume it's a non-issue with J9 as well. I have updated the summary to be specific to the Sun VM. I haven't yet tested with "Java SE 6 Update 10 Beta". This is the only instance of Eclipse having regular catastrophic failures (i.e. exit without warning or failure to draw the error dialog) that I know of. I believe that with the increasing adoption of Vista and of Eclipse/RCP-based applications, it will become an increasingly frequent problem. If a solution is elusive, is there a workaround solution that could help? For example, is it feasible to do something weird like having an error dialog hold on to an appropriate number of color handles that get disposed if "org.eclipse.swt.SWTError: No more handles" is encountered?
*** Bug 237883 has been marked as a duplicate of this bug. ***
Marking as critical since at least from Mylyn bugs and support, it appears that this is now the most common way to get Eclipse to die on Windows. The situation will continue getting progressively worse as more Eclipse extensions and RCP apps get deployed. The problem is still present in the Java SE 6 Update 10 Beta. I'm not sure if there are other work arounds, but the current ones that I'm aware of are both problematic: * Run on J9 or JRockit: the Sun VM is very popular and the only one that's easy to get * Change the process or global handle max in the registry (e.g., http://support.microsoft.com/kb/327699): not something user should do, if multiple RCP apps start doing this we'll get into a mess Is this worth putting on the table for the Eclipse 3.5 cycle? It seems that there are a few things worth exploring: 1) File a bug against Sun for their suspiciously high use of handles 2) Make Eclipse fail gracefully (comment#9 second paragraph)
(In reply to comment #11) > * Run on J9 or JRockit: the Sun VM is very popular and the only one that's easy > to get I switched to jrockit (R27.5.0) yesterday, but i got 2 times in the day the bug 233359.
I don't think this is just limited to Windows Vista; the same issue occurs on my Windows XP machine (32 bit). I have three Eclipse processes running right now with 427, 430, and 1761 GDI objects each. This is fairly normal and means that I can't run too much at once, I think I am hitting the 10k handle limit on XP as well. Also using the Sun JVM 1.6.0_20-b02, Eclipse 3.5.2 build M20100211-1343.
Do we have a leak in SWT ? After reading the comments it seems the user is either running too many applications at once (running out of memory) or there is bug in the VM. Either way this bug should be closed as NOT_ECLIPSE, right ? Lowering priority to normal (critical means we can't ship 3.6)
I don't think it's a leak (the number of handles don't appear to increase noticably over days of uptime), but the sheer number of handles it uses is worrying. I'm not an expert in SWT but any ideas why Eclipse would use so many?
*** Bug 316428 has been marked as a duplicate of this bug. ***
For those that are experiencing a similar issue, you may be running out of desktop heap, rather than GDI handles. Windows, by default, has a desktop heap limit of 3 MB out of a shared heap limit of 20 MB. It is not difficult to hit this limit (especially if you have Windows Explorer running in separate processes). You can increase the desktop heap limit to try and solve this problem. More information: http://journals.jevon.org/users/jevon-phd/entry/19833
*** Bug 341466 has been marked as a duplicate of this bug. ***
this blocker problem still here with eclipse 4.7.3
Vista is no longer supported.
I added same bug but for Windows10 and Eclipse 4.7.3 Windows10 default GDIObjects limit is reached after few minutes, after an hour or two even changed limit of 50000 is reached
(In reply to Miroslav Zat'ko from comment #21) > I added same bug but for Windows10 and Eclipse 4.7.3 See bug 533638.
