Community
Participate
Working Groups
I had a UI freeze during the move of a transition within the Papyrus state-machine diagram. I kept the stack trace (bug occurred in 2nd instance in debug mode, interrupted main several times, showed identical trace). While the error occurs within Papyrus, the involved classes (notably DiagramGraphicalViewer) let me think that it might be a GMF issue, but it could -of course- also be a Papyrus issue. Might be specific to Linux/GTK. Unfortunately, I cannot reproduce it for the moment. Thread [main] (Suspended) owns: DiagramGraphicalViewer$ToggleUpdateManager (id=215) owns: RunnableLock (id=216) ArrayList<E>.indexOf(Object) line: 317 ArrayList<E>.contains(Object) line: 300 DiagramGraphicalViewer$ToggleUpdateManager(DeferredUpdateManager).addInvalidFigure(IFigure) line: 131 LightweightSystem$RootFigure(Figure).revalidate() line: 1451 FreeformViewport(Figure).revalidate() line: 1453 FreeformLayeredPane(Figure).revalidate() line: 1453 FreeformLayer(Figure).revalidate() line: 1453 LineSegMoveInvisibleHandle(Figure).revalidate() line: 1453 LineSegMoveInvisibleHandle(AbstractHandle).ancestorMoved(IFigure) line: 89 AncestorHelper.fireAncestorMoved(IFigure) line: 104 AncestorHelper.figureMoved(IFigure) line: 91 FreeformLayeredPane(Figure).fireFigureMoved() line: 496 FreeformLayeredPane(Figure).setBounds(Rectangle) line: 1524 FreeformHelper.setFreeformBounds(Rectangle) line: 87 FreeformLayeredPane.setFreeformBounds(Rectangle) line: 106 FreeformHelper.setFreeformBounds(Rectangle) line: 94 RenderedDiagramRootEditPart$DiagramRenderedScalableFreeformLayeredPane(FreeformLayeredPane).setFreeformBounds(Rectangle) line: 106 FreeformHelper.setFreeformBounds(Rectangle) line: 94 FreeformLayeredPane.setFreeformBounds(Rectangle) line: 106 FreeformViewport.readjustScrollBars() line: 72 FreeformViewport(Viewport).validate() line: 381 LightweightSystem$RootFigure(Figure).validate() line: 1901 DiagramGraphicalViewer$ToggleUpdateManager(DeferredUpdateManager).performValidation() line: 221 DiagramGraphicalViewer$ToggleUpdateManager.performValidation() line: 116 DiagramGraphicalViewer$ToggleUpdateManager(DeferredUpdateManager).performUpdate() line: 193 DiagramGraphicalViewer$ToggleUpdateManager.performUpdate() line: 106 DeferredUpdateManager$UpdateRequest.run() line: 44 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 182 Display.runAsyncMessages(boolean) line: 4517 Display.readAndDispatch() line: 4135 PartRenderingEngine$4.run() line: 1119 Realm.runWithDefault(Realm, Runnable) line: 336 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1020 E4Workbench.createAndRunUI(MApplicationElement) line: 150 Workbench$5.run() line: 687 Realm.runWithDefault(Realm, Runnable) line: 336 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 604 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 148 IDEApplication.start(IApplicationContext) line: 138 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 388 EclipseStarter.run(String[], Runnable) line: 243 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 Main.invokeFramework(String[], URL[]) line: 673 Main.basicRun(String[]) line: 610 Main.run(String[]) line: 1519 Main.main(String[]) line: 1492
Hi Ansgar, the stack looks similar to the one in bug #155243, which was apparently caused by cyclic connections. I'm not familiar with Papyrus's state-machine diagrams, does it feature connections-on-connection? Or maybe just note attachments on connections? Were you able to reproduce it since the initial report? From what I understand of the exchanges at the time, the bug was fixed by applying https://bugs.eclipse.org/bugs/attachment.cgi?id=50426&action=diff in org.eclipse.gmf.runtime.diagram.ui.editparts.ConnectionNodeEditPart. It looks like the code is still there. Either you're hitting a similar but slightly different case, or maybe Papyrus has a subclass of ConnectionNodeEditPart which does not check for isCyclicConnectionRequest?
