Community
Participate
Working Groups
Build Identifier: I just wanted to use Xtend editor's Content Assist. Unfortunately the UI thread doesn't respsond anymore. Threadsdump is attached. Reproducible: Sometimes
Created attachment 208422 [details] Thread dump
Created attachment 208423 [details] Thread dump (text hover) The problem occurs with on hover, too.
Yuck! Looks like the fix for bug 358396 doesn't quite cut it when you also throw content assist into the mix. So we now have the validation job, the reconciler, and the UI thread (content assist) all waiting for the occurrence marker, which in turn waits on the UI thread. Should maybe the content assist be delegated to a worker thread? I think the JDT may do something like that. I remember seeing dedicated timeout messages on rare occasions, when the content assist wasn't responsive enough.
Ok, therefore disabling "Mark occurences" again should work as workaround, right? Feels like a déjà vu ;-)
(In reply to comment #4) > Ok, therefore disabling "Mark occurences" again should work as workaround, > right? Feels like a déjà vu ;-) Yes, that should do it. It's a lock order inversion problem. I think the DefaultOccurrenceComputer should have its own implementation of EditorResourceAccess overriding getOpenDocument() to return the reference to the document it already has. Then the UI thread would not be required. But then again this is probably a general problem of EditorResourceAccess. Of course it only affects clients which don't already run in the UI thread. So I suppose the EditorResourceAccess#getOpenDocument() implementation should additionally assert that it is executing in the UI thread.
Created attachment 208553 [details] Avoid using accessing the UI thread in DefaultOccurrenceComputer Here's a patch to resolve this issue: As the DefaultOccurrenceComputer already locks the document, it should be safe to use a SimpleLocalResourceAccess, i.e. use the current document's resource set to resolve local cross references. So there is no need to access the UI thread while calculating the annotations. Knut, what do you think?
Hi Jan Yes, you're right, that would solve this particular problem. But I find it somewhat discomforting and inelegant that deadlocks are still possible when using the EditorResourceAccess directly or indirectly (e.g. through the reference finder API) inside an IXtextDocument transaction and when not executing in the UI thread. I think it would be good if we could avoid this situation completely or detect it and raise an exception when it occurs. Any thoughts on this?
Introduced a OpenDocumentTracker for the EditorResourceAccess that doesn't need a document lock and is populated by means of Part/PageListeners. Also added the proposed fix in the occurrence computer.
Should I be worried by (repeatedly) seeing this bug in Xtext 2.2.1, while the fix is supposed to be in 2.2.0 M5? But then, 2.2.1 is actually 2.2.1.v201112130541 which seems to pre-date the fix in this bug, hm? :-/
We use the version tag to determine in which version the bug was found. The fix is in M5 of juno (2.3.0 stream).
(In reply to comment #10) > We use the version tag to determine in which version the bug was found. Thanks, of course, I should know. Sorry. > The fix is in M5 of juno (2.3.0 stream). The confusing part is that "M5" is unqualified. Will this be the only M5 in the project's life time? ;-P For reference: in platform projects this would be "2.3 M5".
The qualifier is the juno flag. However, this is only sufficient as long as we only have releases aligned with the train, which no longer do.
Closing all bugs that were set to RESOLVED before Neon.0
