Community
Participate
Working Groups
Created attachment 258908 [details] ZIP containing thread dumps, system information, and screenshot On separate occasions I have observed the UI freezing on Mars.1 when editing an EMF instance via the Properties view. The first was going through a Vogella EMF tutorial [0] around section 5.4. The second was going through the Xcore tutorial [1] in the 'Creating a Dynamic Instance' section towards the end. In both cases, I was interacting with the Properties view editor. I've had to force quit Eclipse in both occasions. During the Xcore tutorial I can have the UI reliably freeze. While the UI temporarily locked up when editing an Author instance, the UI fully freezes when editing the Copyright field of a Book instance. There are thread dumps in both cases via jvisualvm: book_threaddump.txt and author_threaddump.txt. This is Eclipse Mars.1 running on Java 1.8. System details attached as arguments-system.txt. Also attached is a screen shot of the running threads from jvisualvm. These are all attached as a ZIP. Please let me know what other information I can provide to help troubleshoot this issue. I'm a novice Eclipse developer. I've marked this issue as 'major' since I plan on using the Properties editors. If there are other workarounds to modify EMF instances (maybe ESON assuming I'm using Xcore?) then I'll try those out. However, it seems the Properties editor shouldn't cause such deadlocks. [0] http://www.vogella.com/tutorials/EclipseEMF/article.html [1] https://wiki.eclipse.org/Xcore
Reseting priority back to 'normal' since I'm unsure on how much it matters right now. I'm interested in learning how to troubleshoot the issue further, however.
The Xcore aspects sounds like a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=467436. The problem here is that loading and editing a dynamic instance involves loading the Xcore model itself, and that in turn loads a huge number of resources to represent classes on the classpath. This gigantic resource set is just very slow to edit, but is not representative of the behavior you'd see in your own generated editor. The tutorial you followed should not lead to such problems, but I don't see any thread dumps which seem related to that. The one stack dump has no EMF things in it, but a bunch of threads doing RMI things and the main thread handling a mouse down event on a tree in some native code. I'm not sure what to make of that. The other dump looks like a reflective editor busy visiting all children of the tree in the UI thread; that's definitely slow for an Xcore dynamic instance as in https://bugs.eclipse.org/bugs/show_bug.cgi?id=467436.
If you find that for your own model's generated editor you have lock ups and long freezes, I'll be interested to help with that. Note that EMF can generate an editor that does live validation and it does that in a background thread, that helps offload the loading of a large resource set to the background thread, assuming the resource set might be large, which for typical use cases, is not the case...
(In reply to Ed Merks from comment #2) > The Xcore aspects sounds like a duplicate of > https://bugs.eclipse.org/bugs/show_bug.cgi?id=467436. The problem here is > that loading and editing a dynamic instance involves loading the Xcore model > itself, and that in turn loads a huge number of resources to represent > classes on the classpath. This gigantic resource set is just very slow to > edit, but is not representative of the behavior you'd see in your own > generated editor. The tutorial you followed should not lead to such > problems, but I don't see any thread dumps which seem related to that. The > one stack dump has no EMF things in it, but a bunch of threads doing RMI > things and the main thread handling a mouse down event on a tree in some > native code. I'm not sure what to make of that. The other dump looks like > a reflective editor busy visiting all children of the tree in the UI thread; > that's definitely slow for an Xcore dynamic instance as in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=467436. Agree, seems similar. Is there enough information to consider this a duplicate? (In reply to Ed Merks from comment #3) > If you find that for your own model's generated editor you have lock ups and > long freezes, I'll be interested to help with that. Note that EMF can > generate an editor that does live validation and it does that in a > background thread, that helps offload the loading of a large resource set to > the background thread, assuming the resource set might be large, which for > typical use cases, is not the case... Will keep that in mind, thanks.
*** Bug 467436 has been marked as a duplicate of this bug. ***
