Community
Participate
Working Groups
I have the Debug tab open all the time. If the tab has content (i.e., a tree with a parent and child only), then Eclipse UI hangs on SetScrollInfo. If the tab does not have content, then I can't get the UI to hang. The Debug tab is tall and wide enough that scroll bars are not needed. Here is the call stack at the time of the hang. "main" #1 prio=6 os_prio=0 cpu=2440609.38ms elapsed=14816.66s tid=0x000001d07e1c8800 nid=0x21c68 runnable [0x00000031b3afd000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.SetScrollInfo(Native Method) at org.eclipse.swt.widgets.Tree.updateScrollBar(Tree.java:5718) at org.eclipse.swt.widgets.Tree.createItem(Tree.java:2160) at org.eclipse.swt.widgets.TreeItem.<init>(TreeItem.java:181) at org.eclipse.swt.widgets.TreeItem.<init>(TreeItem.java:142) at org.eclipse.jface.viewers.TreeViewer.createNewRowPart(TreeViewer.java:776) at org.eclipse.jface.viewers.TreeViewer.newItem(TreeViewer.java:276) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:850) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2800) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1958) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:684) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1964) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:684) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1934) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1891) at org.eclipse.jface.viewers.StructuredViewer.lambda$3(StructuredViewer.java:1482) at org.eclipse.jface.viewers.StructuredViewer$$Lambda$587/0x0000000100926840.run(Unknown Source) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1398) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:365) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1359) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1482) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:538) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1443) at org.eclipse.ui.internal.views.markers.UIUpdateJob.runInUIThread(UIUpdateJob.java:103) at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:95) at org.eclipse.ui.progress.UIJob$$Lambda$1147/0x0000000100ee6440.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) - locked <0x00000000be018160> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4035) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3635) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1154) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1045) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) at org.eclipse.ui.internal.Workbench$$Lambda$220/0x0000000100470840.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.12/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.12/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.12/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@11.0.12/Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596) at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
I used to have the Debug tab always visible. I moved the tab to be in a list of tabs and selected a different tab. Eclipse UI does not hang even if there is content in the Debug tab.
I spoke too soon. Eclipse UI just hanged with a hidden Debug tab and content in the tab.
This time the hang happened on OS.GetScrollBarInfo()
Hold on. Let me collect a JFR. My assumptions about the Debug tab are incorrect.
Created attachment 287795 [details] Java Flight Recording Here is the Java Flight Recording that captures the UI hang.
From just some stacktrace is it hard to diagnose if it is one long running method, or that the method is called often. I couldn't find this in the JFR output. Would you be able to do profiling [1] (e.g. jvisualvm) and attach the output? [1] https://wiki.eclipse.org/How_to_report_a_deadlock
The JFR is attached. I see it in the "Attachments" box above the comments and above the status.
(In reply to Nathan Reynolds from comment #7) > The JFR is attached. I see it in the "Attachments" box above the comments > and above the status. That tool is new to me, so took me a while to find the relevant data. In your stack-trace in comment 1, as well as in the JFR attachment, the org.eclipse.ui.internal.views.markers.UIUpdateJob is running. Therefore, this related to the Markers view. Do you have the Marksview open too? From the JFR, it seems that many markers are removed (and added) on the tree update. What is the content of the Markers view, how many items do you allow to be shown per group?
I do not have the "Markers" tab open. I opened it and the summary says 41,530 items. I then expanded the "PMD Markers (39632 items)" tree node. The Eclipse UI hung. After a bit, all of the items in the group are appearing. I then changed the setting to limit each group to 100 items. The Eclipse UI hung. After a bit, up to 100 items in each group are appearing. I tried to reproduce the hang and I cannot. So, the limit is the workaround. So, I see two solutions to implement. First, if the Markers tab is not showing, then don't populate the tree. Second, if the Markers tab is showing and it is causing the UI to hang, then notify the user. If the hang is > X seconds, then show a popup after the UI recovers. If the hang is < X seconds, then add a warning in the Error Log so that users can see what is causing the hang.
