|
| Re: UI "deadlock" due to concurrent XtextDocument/AbstractReadWriteAcces.readOnly [message #1128298 is a reply to message #1118475] |
Mon, 07 October 2013 14:50  |
 Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
Yes, please upgrade to the latest Xtext version. We fixed a couple of
concurrency issues in 2.4.x.
Am 27.09.13 14:48, schrieb Michael Vorburger:
> Hello gurus, we have an end-users reporting a "regularly happening but
> not reliably reproducible UI deadlock" (not technically a JVM deadlock,
> of course), with the following thread dump snapshot (lot's of irrelevant
> stuff removed):
>
> "Worker-64" daemon prio=6 tid=0x54f97c00 nid=0x15f0 runnable
> [0x610cf000..0x610cf9e8]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:347)
> at java.util.HashMap.containsKey(HashMap.java:335)
> at
> com.odcgroup.mdf.validation.validator.MdfValidatorAdapter.hasProcessed(MdfValidatorAdapter.java:70)
>
> at
> com.odcgroup.mdf.validation.validator.MdfValidatorAdapter.validate(MdfValidatorAdapter.java:43)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:171)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:158)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:185)
>
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:185)
>
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
> at
> org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36)
>
> at
> org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:120)
> at
> org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:108)
>
> at
> org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:79)
>
> at
> org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:1)
>
> at
> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.readOnly(AbstractReadWriteAcces.java:32)
>
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:78)
>
> at
> org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(ValidationJob.java:75)
>
> at
> org.eclipse.xtext.ui.editor.validation.ValidationJob.run(ValidationJob.java:64)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> "Worker-57" daemon prio=6 tid=0x59f1e800 nid=0x78c waiting on condition
> [0x5b47f000..0x5b47fb68]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x109f5430> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
>
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807)
>
> at
> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.modify(AbstractReadWriteAcces.java:45)
>
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:181)
>
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:90)
>
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:44)
>
> at
> org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:254)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> "main" prio=6 tid=0x0022ac00 nid=0x1b50 waiting on condition
> [0x0057e000..0x0057fe30]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x109f5430> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:877)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1197)
>
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)
>
> at
> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.readOnly(AbstractReadWriteAcces.java:28)
>
> at
> org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:78)
>
> at
> org.eclipse.xtext.ui.editor.hover.AbstractEObjectHover.getHoverRegion(AbstractEObjectHover.java:52)
>
> at
> org.eclipse.xtext.ui.editor.hover.AbstractCompositeHover.getHoverRegion(AbstractCompositeHover.java:62)
>
> at
> org.eclipse.jface.text.TextViewerHoverManager.computeInformation(TextViewerHoverManager.java:140)
>
> at
> org.eclipse.jface.text.AbstractInformationControlManager.doShowInformation(AbstractInformationControlManager.java:1131)
>
> at
> org.eclipse.jface.text.AbstractHoverInformationControlManager$MouseTracker.mouseHover(AbstractHoverInformationControlManager.java:519)
>
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:207)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
> [...the usual...]
>
> Any tips what to make of this - have we possible hit an Xtext
> concurrency bug, is the Worker-57 stepping on the toes of main? (This
> was seen on our v2.3.1-based IDE - any reason to think that in 2.4.x
> this would be different / better?)
>
> Or is this more likely caused by a... "misuse of Xtext API" in our
> (in-house / non-OSS) code.. is it a problem that our Validation stuff in
> Worker-64 runs inside an AbstractReadWriteAcces/XtextDocument.readOnly
> lock? But we cannot really control that, can we?
>
> Help! ;) Much appreciated.
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
Powered by
FUDForum. Page generated in 0.04086 seconds
] 
Search
Help
Register
Login
Home
Much appreciated.
