Bug 355337

Description Robert Wloch 2011-08-22 01:59:03 EDT

What happens?

Eclipse freezes. It doesn't totally crash, but becomes unusable and unresponsive to any input.


When does this happen?

You need to work on several Papyrus UML diagrams for at least 1 hour. Sometimes it takes 2 or 3 hours, depending on what you do when using Papyrus.


What is my environment?

Windows 7 64 bit, Eclipse Indigo Modeling tools with Papyrus 0.7.0 from update site. Oracle JDK 1.6 update 26. I had this crash with both 32 bit and 64 bit Java+Eclipse. Memory: 8 GB. Harddisk: 250 GB SSD. Graphics: Nvidia Geforce GT 330M with 512 MB.


What does the error log say?

95% nothing. Just once in about 20 crashes I did spot an SWTException fired by TabbedPropertyPage reporting to be out of OS resources or something similar. However, in that stack trace I could not spot any Papyrus class. It seems the crash is so severe, that Eclipse doesn't get a chance to write the error log most of the time.


What causes the crash?

I'm not 100% sure about this, but it seems to be related to the way Papyrus fills the TabbedPropertiesPage. But this *could potentially* be a general TabbedPropertiesPage bug!
The crash always appeared on a context switch in the properties view, e.g. either by selecting a figure or connection in a diagram or by selecting a model object in the model browser.


Why do I think it is Papyrus's TabbedPropertiesPage causing this?

Well the one StackTrace that I saw pointed to a limit of OS Handles that was reached by SWT. A co-worker was luckier with Google than I was and he found a discussion about similar crashes (out of OS resources) reported by Adobe users. In that discussion someone pointed to this microsoft page: http://msdn.microsoft.com/en-us/library/ms724291(v=vs.85).aspx
The page points to an artificial limit of GDI handles that exists on Windows PCs. It also shows a preliminary workaround (see below).

So, to connect Papyrus' TabbedPropertiesPage with hitting the GDI limit I downloaded the Sysinternals Suite for Windows and used the Process Explorer that comes with it. Starting Eclipse and loading my diagrams I checked the number of GDI objects used by Eclipse by viewing the detail of the Eclipse process in the Process Explorer. It number average at about 960. I started doing stuff with Papyrus (create new diagram, new figures and connections in a diagram, switched to the model browser, selected several objects in the model browser and diagram, dragged model objects into the diagram, etc.)
After a while I ran the garbage collector and then checked the number of GDI objects with the Process Explorer. It average at about 1100 and never fell back below 1000.
I continued working on my diagrams. After about 2 hours Eclipse froze. No exception in the log again. As the process was still running I checked the number of GDI objects with the Process Explorer: 9986 just below the limit on Windows 7.


Is there a workaround?

Yes and no.
Yes, because on the Microsoft page linked above it is mentioned that the limit of GDI objects per process is stored in a registry key. So, if you have an admin account you can change that to any value up to the theoretical maximum.
No first, because not everyone as admin rights to do that and no second, because this just extends the time span until Eclipse/SWT/Papyrus/TabbedPropertiesPage runs out of available OS resources (=GDI objects). In other words: The crash would simply happen later.


Why do I think it affects *all* Windows OSs but no others?

GDI objects are a Windows specific operating system resource. The registry key seems to exist in other versions but Windows 7, too, but with a different limit. As it is a Windows specific OS resource, I'd say that other OSs don't have it. However, there'll be something similar and it might be, that the bug is reproducible there, too. But I didn't check that.


Is there more information about this bug?
I wrote this blog post (http://www.robertwloch.net/2011/08/10000-gdi-objects-ought-to-be-enough-for-anybody/) prior to this bug report, so I might have missed to mention something here.