Community
Participate
Working Groups
This deadlock happened during EclipseCon Europe, when you are going through the scenario of having a VSM you are tweaking while having an opened diagram, at some point if you add a Mapping with a WorkspaceImage style the eclipse seems frozen when hitting save on the VSM editor. I got hit by the exact same issue during EclipseCon NA 2014, at that time I narrowed it down to some network related delay (which looked plausible as conference wifi is poor in general) and tracked down a call to Inet6AddressImpl.lookupAllHostAddr(String) Let me wrap a simple reproduction case first.
Created attachment 242287 [details] Archited Projects to import to reproduce the bug
Steps to reproduce: 1- import the projects which are in the zip 2- open My.odesign with the VSM editor 3- delete the EClass mapping, save 4- open the bug433414.modeling project and create a new "Bug433414 diagram on top of the EPackage 5- keep both editors (diagram and VSM) visible at the same time 6- give focus to the VSM Editor 7- hit CTRL-Z (to retrieve the EClass mapping which refers to a workspace image) 8- hit save => Eclipse should be UI locked, the Java process use 0 yet you can't do anything.
Looks like the Inet/Network lead was unrelated. Following the steps given in the previous comment I can reproduce the problem even with a disabled network.
In the deadlock situation I have : TransactionUtil.runExclusive(domain, runnable); in org.eclipse.sirius.business.internal.session.danalysis.DAnalysisSessionServicesImpl.getRepresentationData(EObject, Collection<DAnalysis>) which is waiting through transactionLock.uiSafeAcquire(!tx.isReadOnly()); in org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.acquire(InternalTransaction) All of this is in the UI Thread as the call comes from org.eclipse.sirius.ui.tools.internal.views.common.SessionWrapperContentProvider.getRepresentationsAssociatedToEObject(EObject) On the other end I have org.eclipse.jface.resource.URLImageDescriptor.createImage(boolean, Device) with is locked too waiting Converter.wcsToMbcs(null, chars, true); in org.eclipse.swt.graphics.Image.initNative(String filename) with filename being my image path. The lock is org.eclipse.swt.internal.Platform.lock This one is launched up by org.eclipse.sirius.diagram.ui.tools.internal.editor.DDiagramEditorImpl.launchRefresh(boolean) through org.eclipse.sirius.diagram.ui.tools.internal.editor.DDiagramEditorImpl.modelerDescriptionFilesLoaded() which triggers a "Refresh Job".
More comments : replacing TransactionUtil.runExclusive(domain, runnable); by runnable.run() make the deadlock disappear (well, not requiring a exclusive access on the model) Everything looks quite fine then. Tweaking the reproduction scenario so that the WorkspaceImage gets added while the editor is closed leads to no lock. Doing the scenario which is supposed to fail but after having been able to load the diagram once with the image being visible lead to no lock. So...the Image creation could lead to some kind of delay/contention which are revealing the problem. ITransactionLock.uiSafeAcquire(boolean) states that : * <b>Note:</b> The current thread must not own my monitor when it calls * this method, otherwise it will cause deadlock. Deadlock would be * guaranteed because every thread waits on a different object that is * not me, so my monitor is <b>not</b> released when the calling thread * blocks. * </p>
I just had another deadlock where the TransactionUtil.runExclusive( call is not comming from the session services but instead from an action which try to update its enablement state. In this case SWT was also stuck at the same place. Those image creation calls are coming from org.eclipse.sirius.diagram.ui.business.internal.query.DNodeQuery.getDefaultDimension() which trigger the image creation just to retrieve its bounds. We might want to avoid that in the first place, this is fairly low in the stack and depending on the UI there is not really desirable.
Updating the code in org.eclipse.sirius.diagram.ui.business.internal.query.DNodeQuery.getDefaultDimension() so that it only use ImageData and no Image instances themselves suppress the deadlock. SVGWorkspaceImageFigure.flyWeightImage( is also used for the same purpose (retrieving width/height), I tried the same scenario but with an SVG image and had no deadlock, that being said we can probably be slightly smarter and avoir depending on swt.Image just to retrieve its bounds as the underlying implementation will create an awt.Image and convert it to an SWT Image.
BTW WorkspaceImageQuery.getDefaultDimension() is looking *very similar* to DNodeQuery.getDefaultDimension(). There is some dupplication to kill in the process here.
Found the real culprit : https://bugs.eclipse.org/bugs/show_bug.cgi?id=265265 on Linux, when using SWT/GTK, there is an additional constraint to creating a new instance of Image: it should be done in the UI thread or it *might* create a deadlock situation. The simplest course of action for us is probably to avoid creating an Image instance in this code path and only rely on ImageDescriptors/ImageData.
Change is here : https://git.eclipse.org/r/#/c/25575/
According to this thread in the forum [1] (if indeed this is the same issue), the behavior could be different between Gtk2 and Gtk3. The poster indicates "I have managed to bypass the problem totally forcing eclipse to launch in GTK2 by disabling GTK3 (SWT_GTK3=0). Using GTK3 always fails with my current setup." [1] https://www.eclipse.org/forums/index.php/t/1076516/#page_top
New Gerrit change created: https://git.eclipse.org/r/125805
