Community
Participate
Working Groups
Build id: I20110613-1736 Happens frequently for me with Topcased 5.0.0 UML editing (http://www.topcased.org/index.php?idd_projet_pere=52&Itemid=60) A tooltip keeps hanging on the screen, with Eclipse itself becoming unresponsive and eating away at one of my CPUs. A "kill -3" shows the following: "main" prio=10 tid=0x0987d800 nid=0x390f runnable [0xb69bb000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2258) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2051) at org.eclipse.ui.internal.LegacyAnimationFeedback.jobInit(LegacyAnimationFeedback.java:105) at org.eclipse.ui.internal.AnimationEngine$3.run(AnimationEngine.java:179) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:164) at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) - locked <0x9e960c80> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Should be a duplicate of bug 345093.
I'm not sure I have waited those 140 seconds as mentioned in the other bug. Anyway, as a workaround for this one, it seems to help turning off "Windows / Preferences / General / Appearance / Enable animations"
I believe the fix for bug#345093 might fix this one as well. Please try 3.8 M3 (which will be available this week) and let us know whether you are still able to reproduce this.
The same symptom using build I20111101-0800 on Ubuntu 11.04 (from the dates I assume I have the fix from bug 345093): A hover was displayed in the Java editor then Eclipse hangs in "main" prio=10 tid=0x09eeb800 nid=0x840 runnable [0xbfd46000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2287) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2053) at org.eclipse.jface.text.AbstractInformationControl.setVisible(AbstractInformationControl.java:505) at org.eclipse.jface.internal.text.html.BrowserInformationControl.setVisible(BrowserInformationControl.java:367) at org.eclipse.jface.text.AbstractInformationControlManager.showInformationControl(AbstractInformationControlManager.java:1270) at org.eclipse.jface.text.TextViewerHoverManager.showInformationControl(TextViewerHoverManager.java:283) at org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(AbstractInformationControlManager.java:1221) at org.eclipse.jface.text.AbstractInformationControlManager.presentInformation(AbstractInformationControlManager.java:1150) at org.eclipse.jface.text.AbstractHoverInformationControlManager.presentInformation(AbstractHoverInformationControlManager.java:902) at org.eclipse.jface.text.TextViewerHoverManager.doPresentInformation(TextViewerHoverManager.java:243) at org.eclipse.jface.text.TextViewerHoverManager$5.run(TextViewerHoverManager.java:233) Another variant: * Opened the pulldown from the "Run" toolbar button. * Menu was frozen during fading (not sure if fade-in or fade-out) * Eclipse was still responsive but menu would not disappear until Eclipse was closed. (sorry, no stack from that situation - pls excuse if unrelated). I only started to see these issues recently. I don't see any relevant libraries (libgtk etc.) that have been updated recently, but java-6-openjdk has been updated recently to java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.4) (6b22-1.10.4-0ubuntu1~11.04.1) OpenJDK Server VM (build 20.0-b11, mixed mode)
I want to let you know that I've also seen this since I've upgraded to opensuse 12.1. I don't recall seeing this before. Here's the stacktrace from JTop: Name: main State: RUNNABLE Total blocked: 1,305 Total waited: 697 Stack trace: org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2276) org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2051) org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.displayProposals(CompletionProposalPopup2.java:683) org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.showProposals(CompletionProposalPopup2.java:227) org.eclipse.jface.internal.text.link.contentassist.ContentAssistant2.showPossibleCompletions(ContentAssistant2.java:1265) org.eclipse.jface.text.link.LinkedModeUI.triggerContentAssist(LinkedModeUI.java:824) org.eclipse.jface.text.link.LinkedModeUI.switchPosition(LinkedModeUI.java:860) org.eclipse.jface.text.link.LinkedModeUI.next(LinkedModeUI.java:799) org.eclipse.jface.text.link.LinkedModeUI.enter(LinkedModeUI.java:718) org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.apply(ParameterGuessingProposal.java:156) org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:477) org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.apply(LazyJavaCompletionProposal.java:488) org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:930) org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:881) org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1307) org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:807) org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491) org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65) org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1061) org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5936) org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5635) org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1294) org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:730) org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3019) org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:734) org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1743) org.eclipse.swt.widgets.Control.windowProc(Control.java:5016) org.eclipse.swt.widgets.Display.windowProc(Display.java:4408) org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8422) org.eclipse.swt.widgets.Display.eventProc(Display.java:1245) org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2276) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3207) org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:597) org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) org.eclipse.equinox.launcher.Main.run(Main.java:1410) org.eclipse.equinox.launcher.Main.main(Main.java:1386)
*** Bug 366960 has been marked as a duplicate of this bug. ***
My filed bug 366960 has been marked as a duplicate of this one. But the workaround with disabling animations didn't make any difference for me. My problem still exists.
I have to restart eclipse at least once nowadays. What seems to be happening is the eclipse is progressively getting worse. In other words, the longer I use eclipse the worse this problem seems to get until it hangs completely. There are also some strange visual artifacts that appear over time. For example, the suggestion box may be show all the items, but half of them are all black text on black background. Or when opening menus, I temporarily get striping artifacts, like only every other line of the menu is rendered.
Happened again. Showing the same stack as in comment 5. Had to kill the Eclipse process -> data loss. Build is I20111209-1447. "Enable animations" is unchecked.
Ditto. Frequent hangs with tooltips in Indigo DLTK. Platform 3.7.1 build 20110916-0149. "main" prio=10 tid=0x09b16c00 nid=0x1ac4 runnable [0xbfb6e000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2276) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2051) at org.eclipse.jface.text.contentassist.ContextInformationPopup.internalShowContextFrame(ContextInformationPopup.java:379) at org.eclipse.jface.text.contentassist.ContextInformationPopup.internalShowContextInfo(ContextInformationPopup.java:284) at org.eclipse.jface.text.contentassist.ContextInformationPopup.access$5(ContextInformationPopup.java:279) at org.eclipse.jface.text.contentassist.ContextInformationPopup$2.run(ContextInformationPopup.java:266) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.text.contentassist.ContextInformationPopup.showContextInformation(ContextInformationPopup.java:257) at org.eclipse.jface.text.contentassist.ContentAssistant.showContextInformation(ContentAssistant.java:1730) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:957) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:881) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1307) at org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:807) at org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491) at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1061) at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5936) at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5635) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1294) at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:730) at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3019) at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:734) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1743) at org.eclipse.swt.widgets.Control.windowProc(Control.java:5016) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4408) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8422) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1245) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2276) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3207) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
*** Bug 376178 has been marked as a duplicate of this bug. ***
Looking at the code in Shell.setVisible() I'd infer the following protocol: 1. we set this.mapped = false; 2. we call OS.g_main_context_iteration in a loop 3. during one of these calls we expect a callback from native GTK into shellMapProc, which sets mapped = true 4. if (mapped) we proceed right? When we get stuck here I only see two possible reasons: a. we never receive a callback to shellMapProc b. we get that callback too early, i.e., before this.mapped = false; E.g., if GTK fires the callback already from OS.gtk_widget_show then we would first set mapped = true (in the callback) then overwrite this with false in Shell.setVisible() and then wait for a callback that has already happened, i.e., wait in vain. I have no idea about the inner workings of GTK but wouldn't this potentially explain the hang?
Happened again with SDK 4.2M6. Eclipse dead. Data loss. Meanwhile I'm on kubuntu 12.04 beta. libgtk-3-0 3.4.0-0ubuntu2
I'm not completely sure if the scenario referred to in comment 12 is possible or not but I've been using 4.2 M6 on Ubuntu 11.04 and I've not hit this issue. Do you think there is any particular set of actions that can trigger the hang?
(In reply to comment #14) > I'm not completely sure if the scenario referred to in comment 12 is possible > or not but I've been using 4.2 M6 on Ubuntu 11.04 and I've not hit this issue. Lucky you. But for several folks this is a severe issue. > Do you think there is any particular set of actions that can trigger the hang? I'm afraid anything that opens a new shell (specifically tooltips) is susceptible to this bug. So I'd say its typically triggered by moving the mouse around. No idea which tooltip was being shown. Well, in fact I seem to remember one instance where a javadoc tooltip was "sticking to the glass" when Eclipse froze. Until s.o. comes up with any explanation or theory would you mind / see problems with just moving the "mapped = false;" line up before the first call into GTK? I guess the stacktraces are the only useful evidence we have. At least we have them!
(In reply to comment #15) > Until s.o. comes up with any explanation or theory would you mind / see > problems with just moving the "mapped = false;" line up before the first call > into GTK? I have tested running Eclipse with the above suggested change and things seem fine but I have no way of verifying if it actually solves the problem you're facing as I don't see the problem in the first place. The change itself seems harmless AFAIK but I'm really not sure if we should do it without having an idea whether it fixes the problem or not. Silenio, what do you think we should do?
Released the proposed change. Please let us know either anyone can still reproduce the problem with the next I-build. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5d1422ebce1c7c15f192a0bcf0fe986785f60685
(In reply to comment #17) > Released the proposed change. Please let us know either anyone can still > reproduce the problem with the next I-build. > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5d1422ebce1c7c15f192a0bcf0fe986785f60685 Cool, thanks. Now all we need is a build :-/
This is still broken for me in the latest Juno update.
Same problem with eclipse juno - stuck while opening completion. stacktrace - http://pastebin.com/ggSYYdE3 Using opensuse 12.1, kde 4.9
The same problem. I can't use ObjectAid plugin for UML. System: Arch Linux 3.4.9 + KDE 4.9 I use Eclipse 4.2.0 (Juno) Stacktrace: http://pastebin.com/TpZ7FHYh
Still a problem in Kepler: "main" prio=10 tid=0x00007f7e8c009000 nid=0xaf8 sleeping[0x00007f7e93ccc000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2287) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2159) at org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.displayProposals(CompletionProposalPopup2.java:683) at org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.showProposals(CompletionProposalPopup2.java:227) at org.eclipse.jface.internal.text.link.contentassist.ContentAssistant2.showPossibleCompletions(ContentAssistant2.java:1265) at org.eclipse.jface.text.link.LinkedModeUI.triggerContentAssist(LinkedModeUI.java:823) at org.eclipse.jface.text.link.LinkedModeUI.switchPosition(LinkedModeUI.java:859) at org.eclipse.jface.text.link.LinkedModeUI.next(LinkedModeUI.java:798) at org.eclipse.jface.text.link.LinkedModeUI.enter(LinkedModeUI.java:717) at org.eclipse.jdt.internal.ui.viewsupport.LinkedProposalModelPresenter.enterLinkedMode(LinkedProposalModelPresenter.java:121) at org.eclipse.jdt.internal.ui.text.correction.proposals.LinkedCorrectionProposal.performChange(LinkedCorrectionProposal.java:159) at org.eclipse.jdt.ui.text.java.correction.CUCorrectionProposal.apply(CUCorrectionProposal.java:184) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:945) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:891) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1323) at org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:808) at org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:491) at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:65) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1416) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1401) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1187) at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5954) at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5636) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1416) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1401) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1428) at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:829) at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3236) at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:758) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2096) at org.eclipse.swt.widgets.Control.windowProc(Control.java:5467) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4569) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8707) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1243) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2287) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3361) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
I'm not doing the Shell.setVizible(), but have a JUnit test hanging in Luna M5 (Fedora 20, x86_64, GTK3, but SWT_GTK=0 used when starting tycho) with the pretty similar stacktrace: "main" prio=10 tid=0x00007f8fe8009800 nid=0x133f runnable [0x00007f8ff0dc2000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3389) Though, when I'm repeatedly executing 'kill -3 PID' the stacktrace is changing a bit showing some more calls in that cycle: "main" prio=10 tid=0x00007f8fe8009800 nid=0x133f runnable [0x00007f8ff0dbc000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_object_get_qdata(Native Method) at org.eclipse.swt.internal.gtk.OS.g_object_get_qdata(OS.java:2691) at org.eclipse.swt.widgets.Display.getWidget(Display.java:2547) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1350) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._Call(Native Method) at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) at org.eclipse.swt.widgets.Shell.fixedSizeAllocateProc(Shell.java:928) at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3389) So, it looks like some infinite cycle of iterations between gkt.OS.* and o.e.swt.widgets.* Objects' methods. When running gdt debugger it doesn't show any segfaults at this moment (but has shown many of them for many of preceding tests). It shows just repeatedly created and exited threads: .... [Thread 0x7f8ed8cf5700 (LWP 15492) exited] [New Thread 0x7f8ed8cf5700 (LWP 15493)] [Thread 0x7f8ed8cf5700 (LWP 15493) exited] [New Thread 0x7f8ed8cf5700 (LWP 15494)] [Thread 0x7f8ed8cf5700 (LWP 15494) exited] [New Thread 0x7f8ed8cf5700 (LWP 15495)] [Thread 0x7f8ed8cf5700 (LWP 15495) exited] ...
(In reply to Victor Rubezhny from comment #23) > I'm not doing the Shell.setVizible(), but have a JUnit test hanging in Luna > M5 (Fedora 20, x86_64, GTK3, but SWT_GTK=0 used when starting tycho) with > the pretty similar stacktrace: > > "main" prio=10 tid=0x00007f8fe8009800 nid=0x133f runnable > [0x00007f8ff0dc2000] > java.lang.Thread.State: RUNNABLE > at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) > at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3389) > > > Though, when I'm repeatedly executing 'kill -3 PID' the stacktrace is > changing a bit showing some more calls in that cycle: > > "main" prio=10 tid=0x00007f8fe8009800 nid=0x133f runnable > [0x00007f8ff0dbc000] > java.lang.Thread.State: RUNNABLE > at org.eclipse.swt.internal.gtk.OS._g_object_get_qdata(Native Method) > at org.eclipse.swt.internal.gtk.OS.g_object_get_qdata(OS.java:2691) > at org.eclipse.swt.widgets.Display.getWidget(Display.java:2547) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1350) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._Call(Native Method) > at org.eclipse.swt.internal.gtk.OS.Call(OS.java:824) > at org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(Widget.java:1031) > at org.eclipse.swt.widgets.Shell.fixedSizeAllocateProc(Shell.java:928) > at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1351) > at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) > at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3389) > > So, it looks like some infinite cycle of iterations between gkt.OS.* and > o.e.swt.widgets.* Objects' methods. > > When running gdt debugger it doesn't show any segfaults at this moment (but > has shown many of them for many of preceding tests). It shows just > repeatedly created and exited threads: > > .... > [Thread 0x7f8ed8cf5700 (LWP 15492) exited] > [New Thread 0x7f8ed8cf5700 (LWP 15493)] > [Thread 0x7f8ed8cf5700 (LWP 15493) exited] > [New Thread 0x7f8ed8cf5700 (LWP 15494)] > [Thread 0x7f8ed8cf5700 (LWP 15494) exited] > [New Thread 0x7f8ed8cf5700 (LWP 15495)] > [Thread 0x7f8ed8cf5700 (LWP 15495) exited] > ... Any chance for a pure SWT testcase/snippet to reproduce your problem?
CQ:WIND00-WB4-5616
Same happens regularly for me on Mars, on a Linux Mint 17.2, Java 1.8.0_45: "main" #1 prio=6 os_prio=0 tid=0x00007ff93000b000 nid=0xd4c runnable [0x00007ff935a0b000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2422) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2310) at org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.displayProposals(CompletionProposalPopup2.java:683) at org.eclipse.jface.internal.text.link.contentassist.CompletionProposalPopup2.showProposals(CompletionProposalPopup2.java:227) at org.eclipse.jface.internal.text.link.contentassist.ContentAssistant2.showPossibleCompletions(ContentAssistant2.java:1265) at org.eclipse.jface.text.link.LinkedModeUI.triggerContentAssist(LinkedModeUI.java:823) at org.eclipse.jface.text.link.LinkedModeUI.switchPosition(LinkedModeUI.java:859) at org.eclipse.jface.text.link.LinkedModeUI.next(LinkedModeUI.java:798) at org.eclipse.jface.text.link.LinkedModeUI.enter(LinkedModeUI.java:717) at org.eclipse.recommenders.completion.rcp.processable.ProcessableParameterGuessingProposal.apply(ProcessableParameterGuessingProposal.java:241 ) at org.eclipse.jdt.internal.ui.text.java.AbstractJavaCompletionProposal.apply(AbstractJavaCompletionProposal.java:504) at org.eclipse.jdt.internal.ui.text.java.LazyJavaCompletionProposal.apply(LazyJavaCompletionProposal.java:489) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertProposal(CompletionProposalPopup.java:963) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.insertSelectedProposalWithMask(CompletionProposalPopup.java:914) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.verifyKey(CompletionProposalPopup.java:1358) at org.eclipse.jface.text.contentassist.ContentAssistant$InternalListener.verifyKey(ContentAssistant.java:814) at org.eclipse.jface.text.TextViewer$VerifyKeyListenersManager.verifyKey(TextViewer.java:493) at org.eclipse.swt.custom.StyledTextListener.handleEvent(StyledTextListener.java:66) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1351) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1336) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1117) at org.eclipse.swt.custom.StyledText.handleKeyDown(StyledText.java:5990) at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5682) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1327) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1351) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1336) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1363) at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:763) at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3317) at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:785) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1965) at org.eclipse.swt.widgets.Control.windowProc(Control.java:5590) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4717) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9272) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1225) The code-complete popup is not really drawn, it's filled with garbage. The only way to get rid of it is to kill Eclipse forcefully and restart it.
It looks like main_context_iteration is the GTK method that invokes the main event loop. Source: https://www.gnu.org/software/guile-gnome/docs/glib/html/The-Main-Event-Loop.html Sergey and I had a brainstorm to discuss possible hypotheses as to what might be going on here. H1. main_context_iteration may be waiting for an event and nothing is ever posted to the event loop. Investigate: check if SWT uses may-block=true on main_context_iteration H2. There may be a slow native event handler responsible for the freezes which we're not seeing on top of the stack trace. Investigate: This requires an explanation for why we don't see the event handler on the stack trace. Lack of debug symbols? Type of calling convention the lib was compiled with? H3. Rather than a single slow operation in main_context_iteration, there could be a long sequence of fast operations. Investigate: If this were the case, we would expect repeated stack traces to look sightly different. The observations of comment 23 are consistent with this hypothesis. H4. The UI thread may be blocked trying to obtain the GTK lock. Other observations: All of the stack traces seem to be triggered by Shell.setVisible. I took a quick look there and found this scary-looking comment: /* * This call to gdk_threads_leave() is a temporary work around * to avoid deadlocks when gdk_threads_init() is called by native * code outside of SWT (i.e AWT, etc). It ensures that the current * thread leaves the GTK lock before calling the function below. */ OS.gdk_threads_leave(); OS.g_main_context_iteration (0, false); This code was added by git commit 0136cb66377527bbec706f0d84b3bcbb5f3b2a23 for bug 341538, one month before this bug was first reported... so I'd guess it's the cause of the slowness.
Looking in the GDK 3 manual, I see that gdk_threads_enter and gdk_threads_leave have been deprecated in favor of gdk_threads_add_idle and gdk_threads_add_timeout (which appear to be equivalent to SWT's Display.asyncExec). https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
The comment made here https://bugs.eclipse.org/bugs/show_bug.cgi?id=341085#c7 explains the rationale behind adding the gdk_threads_leave call. We need to investigate further on correct approach for this
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness This blog post has tested the use of gdk_threads_set_locking_function to create reentrant locks as Silenio mentions in that bug. They say it works fine. If that's the case, why not coordinate with AWT to do exactly what he suggests in bug 341085, comment 7? If a coordinated fix with AWT is infeasable, we could try taking our synchronous lock acquisition code and running it asynchronously using gdk_threads_add_idle. That should work regardless of where it is invoked from and whether or not the caller has already acquired a lock.
It's still not obvious to me why releasing the lock early is causing Eclipse to freeze... but here's my guess: I'd bet there's some code in WebKit that is holding the lock for an extended amount of time (possibly while performing a network round-trip or while waiting for events). By releasing the lock early, SWT is permitting WebKit to acquire it which unblocks WebKit but blocks SWT. I suspect WebKit because it's used in a lot of these hovers that we're seeing on the stack traces, and Silenio called it out directly as being related to this lock acquisition problem.
Users are reporting high CPU usage during the freeze.
(In reply to Stefan Xenos from comment #27) > H1. main_context_iteration may be waiting for an event and nothing is ever > posted to the event loop. Investigate: check if SWT uses may-block=true on > main_context_iteration This sounds plausible. I'm in the process of porting the Equinox launcher to Wayland, and part of that involves making sure the platform UI elements run by Equinox launch properly on Wayland. This includes things like the workspace chooser, splash screen, etc. I've noticed when running on Wayland, there seems to be an infinite loop condition in Window.java:825. This is reproducible on some JFace snippets, such as this one: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.jface.snippets/Eclipse%20JFace%20Snippets/org/eclipse/jface/snippets/dialogs/Snippet012DialogWithImageButtons.java In this case, it seem the main_context_iteration call is being made to look for events, but the actual event queue is empty. This causes runDeferredEvents() and readAndDispatch() methods in Display.java to return false and true, respectively. This causes the infinite while loop in Window.java. I haven't fully investigated this further, but they do seem related.
Alright, I can confirm that the Wayland issue has its roots in Shell.setVisible() as well. In my case it seems to be Wayland specific, as the snippet I posted earlier runs on X11, but seeing how others have had trouble with this means it's not Wayland specific.
(In reply to Alexander Kurtakov from comment #24) > (In reply to Victor Rubezhny from comment #23) > > I'm not doing the Shell.setVizible(), but have a JUnit test hanging in Luna > > M5 (Fedora 20, x86_64, GTK3, but SWT_GTK=0 used when starting tycho) with > > the pretty similar stacktrace: > > > > "main" prio=10 tid=0x00007f8fe8009800 nid=0x133f runnable > > [0x00007f8ff0dc2000] > > java.lang.Thread.State: RUNNABLE > > at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) > > at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) > > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3389) > > Any chance for a pure SWT testcase/snippet to reproduce your problem? This particular stack trace can be reproduced by running the Equinox launcher on Wayland, or by running Snippet012DialogWithImageButtons.java (http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/examples/org.eclipse.jface.snippets/Eclipse%20JFace%20Snippets/org/eclipse/jface/snippets/dialogs/Snippet012DialogWithImageButtons.java) on Wayland. Equinox launcher trace: at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3418) at org.eclipse.jface.window.Window.runEventLoop(Window.java:827) at org.eclipse.jface.window.Window.open(Window.java:803) at org.eclipse.ui.internal.ide.ChooseWorkspaceDialog.prompt(ChooseWorkspaceDialog.java:93) at org.eclipse.ui.internal.ide.application.IDEApplication.promptForWorkspace(IDEApplication.java:343) at org.eclipse.ui.internal.ide.application.IDEApplication.checkInstanceLocation(IDEApplication.java:262) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:128) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608) at org.eclipse.equinox.launcher.Main.run(Main.java:1515) at org.eclipse.equinox.launcher.Main.main(Main.java:1488) Snippet012 trace: at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3415) at org.eclipse.jface.window.Window.runEventLoop(Window.java:827) at org.eclipse.jface.window.Window.open(Window.java:803) at org.eclipse.jface.snippets.dialogs.Snippet012DialogWithImageButtons.<init>(Snippet012DialogWithImageButtons.java:67) at org.eclipse.jface.snippets.dialogs.Snippet012DialogWithImageButtons.main(Snippet012DialogWithImageButtons.java:78)
(In reply to Victor Rubezhny from comment #23) We've seen a very similar backtrace as comment 23 on Ubuntu 12.04.5 LTS 64bit (on initial start while the Welcome Page should be displayed), as well as CentOS 6.6 64bit (when quickly dragging the Workbench Window). On Ubuntu, I see System Property org.eclipse.swt.internal.gtk.version=2.24.10 The issue occurs infrequently, but it's a UX killer when it does occur so I'm quite concerned. We launch our product with "--launcher.GTK_version 2". Is there a chance that this problem might be gone with GTK3 ? CQ:WIND00-WB4-5655
This is happening for me as well. Eclipse 4.5.0 "main" #1 prio=6 os_prio=0 tid=0x00007f60dc009000 nid=0x73e7 runnable [0x00007f60e153e000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2422) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2310) at org.eclipse.jface.text.AbstractInformationControl.setVisible(AbstractInformationControl.java:505) at org.eclipse.jface.text.AbstractInformationControlManager.showInformationControl(AbstractInformationControlManager.java:1270) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.showInformationControl(MultipleHyperlinkPresenter.java:655) at org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(AbstractInformationControlManager.java:1221) at org.eclipse.jface.text.AbstractInformationControlManager.presentInformation(AbstractInformationControlManager.java:1150) at org.eclipse.jface.text.AbstractInformationControlManager.setInformation(AbstractInformationControlManager.java:418) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.computeInformation(MultipleHyperlinkPresenter.java:632) at org.eclipse.jface.text.AbstractInformationControlManager.doShowInformation(AbstractInformationControlManager.java:1131) at org.eclipse.jface.text.AbstractInformationControlManager.showInformation(AbstractInformationControlManager.java:1121) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter.showHyperlinks(MultipleHyperlinkPresenter.java:857) at org.eclipse.jface.text.hyperlink.HyperlinkManager.showHyperlinks(HyperlinkManager.java:575) at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:470) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:212)
I can reproduce the problem with Version: Mars.1 Release (4.5.1) Build id: 20150924-1200. Interestingly, downgrading GTK+3 from 3.18.2 to 3.16.7 solves the issue for me.
(In reply to Danilo Pianini from comment #38) > I can reproduce the problem with Version: Mars.1 Release (4.5.1) Build id: > 20150924-1200. > Interestingly, downgrading GTK+3 from 3.18.2 to 3.16.7 solves the issue for > me. And by solves, do you mean "it hasn't happened yet" or do you have a realiable way of recreating it? The reason I ask, is mine can go for a week without an issue and then crash twice in an hour. I have Fedora Core 20, gtk3.x86_64 3.10.9-2.fc20, gtk2.x86_64 2.24.24-2.fc20
> crash twice in an hour If it's crashing, you may be experiencing a different bug.
(In reply to Andrei Solodin from comment #39) > And by solves, do you mean "it hasn't happened yet" or do you have a > realiable way of recreating it? The reason I ask, is mine can go for a week > without an issue and then crash twice in an hour. > > I have Fedora Core 20, gtk3.x86_64 3.10.9-2.fc20, gtk2.x86_64 2.24.24-2.fc20 I do have a reliable way of recreating it. Fire up eclipse, open a workspace with a project using Git for versioning, open the Git Staging view, do some change in a file, try to drag and drop staging files to the area where files that are going to be committed stand. This kicks the bug in, and one CPU core goes mad. I am trying with more combinations. I am running Antergos Linux (Arch based): 4.2.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux gtk3-3.18.2-1-x86_64 has the issue, gtk3-3.16.7-1-x86_64 does not. I am going to test gtk3-3.18.1-1-x86_64, and will report back.
The issue still stands with gtk3-3.18.1-1-x86_64.
I believe I stumbled upon same or very simmilar issue. My environment is Fedora 23 (gtk3 version 3.18.2). I have tried it on two Fedora 23 machines and I noticed interesting thing. The issue only happened with Plasma desktop environment. When I switched to Gnome (still using GTK3), issue didn't happen. The issue also didn't happen with GTK2 on Plasma.
New Gerrit change created: https://git.eclipse.org/r/60027
The issue has been introduced by GTK 3.17.4 with commit https://git.gnome.org/browse/gtk+/commit/?id=fe51ac273c8045279a222c22a52d297d5ede4169 The commit causes Eclipse to continuously receive a paint event. Attached is a snippet. It will print "Paint" continuously on GTK >= 3.17.4 even if a shell is minimized. On Ubuntu 15.04 with GTK 3.18.2 and GTK 3.18.3 compiled, I have also noticed the following issues: - only the first page in Window>Preferences is shown - Eclipse freezes when starting the Git Commit Dialog wizard These issues aren't reproducible on Fedora 23. https://git.eclipse.org/r/60027 fixes these two issues on Ubuntu 15.04. However, the patch doesn't fix the issue related to a paint event that consumes CPU while idling. It can also be reproduced on Fedora 23. In my opinion, the issue has to be fixed upstream (in GTK).
Created attachment 257849 [details] A snippet
(In reply to Snjezana Peco from comment #45) > The issue has been introduced by GTK 3.17.4 with commit > https://git.gnome.org/browse/gtk+/commit/ > ?id=fe51ac273c8045279a222c22a52d297d5ede4169 It is good to see work on the fix, however: I am running Ubuntu 14.04 vanilla, with it's vanilla repository gtk version https://launchpad.net/ubuntu/trusty/+source/gtk+3.0 gtk+3.0 3.10.8-0ubuntu1 and still get this bug. Can it really be introduced in GTK 3.17 then?
(In reply to Danielius Kudinskas from comment #47) > > It is good to see work on the fix, however: I am running Ubuntu 14.04 > vanilla, with it's vanilla repository gtk version > https://launchpad.net/ubuntu/trusty/+source/gtk+3.0 > gtk+3.0 3.10.8-0ubuntu1 > > and still get this bug. Can it really be introduced in GTK 3.17 then? Can you reproduce the issue using the attached snippet?
(In reply to Snjezana Peco from comment #48) Snjezana, I could not reproduce the problem using your code.
(In reply to Andrei Solodin from comment #49) > (In reply to Snjezana Peco from comment #48) > Snjezana, I could not reproduce the problem using your code. What Linux distribution (GTK version) are you using?
(In reply to Snjezana Peco from comment #50) > (In reply to Andrei Solodin from comment #49) > > (In reply to Snjezana Peco from comment #48) > > Snjezana, I could not reproduce the problem using your code. > > What Linux distribution (GTK version) are you using? I have Fedora Core 20, gtk3.x86_64 3.10.9-2.fc20, gtk2.x86_64 2.24.24-2.fc20
(In reply to Andrei Solodin from comment #51) > I have Fedora Core 20, gtk3.x86_64 3.10.9-2.fc20, gtk2.x86_64 2.24.24-2.fc20 In order to reproduce the issue you need gtk3 3.18 (Fedora 23, for instance).
(In reply to Snjezana Peco from comment #52) > (In reply to Andrei Solodin from comment #51) > > I have Fedora Core 20, gtk3.x86_64 3.10.9-2.fc20, gtk2.x86_64 2.24.24-2.fc20 > > In order to reproduce the issue you need gtk3 3.18 (Fedora 23, for instance). Ok, I am not sure what issue you are talking about then. The bug affecting me is described in this thread.
Snjezana, I can't reproduce with your snipped on Fedora 23 (gtk 3.18.5) too. Would you please check again and at least explain in details what to look for in case I'm just missing it.
I tried that snippet on Fedora 23 (gtk3.18.5). When you ran the snippet with GTK2, there is just few paint events (you can see "Paint" in console just few times). But when it's run with GTK3, you can see in console output, that the Paint event is called again and again...
(In reply to Alexander Kurtakov from comment #54) > Snjezana, I can't reproduce with your snipped on Fedora 23 (gtk 3.18.5) too. > Would you please check again and at least explain in details what to look > for in case I'm just missing it. My snippet is related to bug 478962. This issue is related to UI freeze. I have reproduced it on Ubuntu with a compiled GTK 3.18.x. Radim has reproduced it in Fedora 23 with the Plasma desktop environment. See comment 43. After applying https://git.eclipse.org/r/61124 (bug 478962), the issue isn't reproducible anymore. I think we would also need to apply https://git.eclipse.org/r/60027 because it would improve performance and maybe fix the issue with Shell.setVisible described in this bug.
(In reply to Snjezana Peco from comment #56) > (In reply to Alexander Kurtakov from comment #54) > > Snjezana, I can't reproduce with your snipped on Fedora 23 (gtk 3.18.5) too. > > Would you please check again and at least explain in details what to look > > for in case I'm just missing it. > > My snippet is related to bug 478962. > > This issue is related to UI freeze. > I have reproduced it on Ubuntu with a compiled GTK 3.18.x. > Radim has reproduced it in Fedora 23 with the Plasma desktop environment. > See comment 43. > > After applying https://git.eclipse.org/r/61124 (bug 478962), the issue isn't > reproducible anymore. So with gerrit 61124 being applied in master gerrit review attached to this patch should be abandoned? Sorry but I find it quite hardly to find my way snippets for one bug attached in another and etc. > I think we would also need to apply https://git.eclipse.org/r/60027 because > it would improve performance and maybe fix the issue with Shell.setVisible > described in this bug.
(In reply to Alexander Kurtakov from comment #57) > (In reply to Snjezana Peco from comment #56) > > (In reply to Alexander Kurtakov from comment #54) > > So with gerrit 61124 being applied in master gerrit review attached to this > patch should be abandoned? Sorry but I find it quite hardly to find my way > snippets for one bug attached in another and etc. > > > I think we would also need to apply https://git.eclipse.org/r/60027 because > > it would improve performance and maybe fix the issue with Shell.setVisible > > described in this bug. I meant both bugs were caused by the same issue.
The issue described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=482915 is again reproducible with the SWT master and GTK 3.18.5. https://git.eclipse.org/r/#/c/60027/ fixes it.
I'm not sure whether this bug covers what a few of users experience with the latest SmartGit 7.1 on different Linux systems. They report that opening the log window does nothing ("hangs"), eats CPU and only can be continued by showing a file-open dialog: https://groups.google.com/d/msgid/smartgit/926c40c1-e46c-4363-b3b5-d2c7e32095af%40googlegroups.com https://groups.google.com/d/msgid/smartgit/94b138fe-fb03-4b3b-9b03-f8b36145857e%40googlegroups.com Thread-dumps show the SWT thread hanging in org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2468) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3441) and failing to execute display.asyncExec(Runnable). Unfortunately, I could not reproduce the hang myself and hence have no exact details under what Linux versions/software installations and what conditions or with which snippet this is reproducible. SmartGit 7.1 uses SWT 4.610 (according to version.txt resource), but people also wrote it would be reproducible with SWT 4.527 from SmartGit 7 - though for SmartGit 7 this problem had not been reported.
Please note, that the hang only occurs for us when having set SWT_GTK3=0 But using GTK3 is no option right now generally, because it still is (except of this hanging) more buggy than GTK2.
People that debug and fix GTK2 issues is constantly decreasing and Eclipse defaults to GTK3. Please make sure that all your GTK3 issues are reported/known. I myself consider GTK2 port in maintenance mode (aka "as long as it works" ).
(In reply to Alexander Kurtakov from comment #62) > I myself consider GTK2 port in maintenance mode (aka "as > long as it works" ). Strange attitude given that GTK2 is currently the only usable platform on Linux. GTK3 is simply not in a usable state right now. So if you break GTK2 nobody can use Eclipse on Linux.
(In reply to Ortwin Glück from comment #63) +1
(In reply to Ortwin Glück from comment #63) +1 By all respect to the tremendous efforts of the RH team to bring GTK3 port to a usable state, I still can't use it and would not recommend to use it to anyone in production environment (based on my personal experience on Fedora 21/RHEL7 and my observations about bugs coming in to the platform tracker).
(In reply to Ortwin Glück from comment #63) > (In reply to Alexander Kurtakov from comment #62) > > I myself consider GTK2 port in maintenance mode (aka "as > > long as it works" ). > > Strange attitude given that GTK2 is currently the only usable platform on > Linux. GTK3 is simply not in a usable state right now. So if you break GTK2 > nobody can use Eclipse on Linux. I confirm: GTK3 is not usable in Linux right now
(In reply to Ortwin Glück from comment #63) > (In reply to Alexander Kurtakov from comment #62) > > I myself consider GTK2 port in maintenance mode (aka "as > > long as it works" ). > > Strange attitude given that GTK2 is currently the only usable platform on > Linux. GTK3 is simply not in a usable state right now. So if you break GTK2 > nobody can use Eclipse on Linux. First of all, I do not intend breaking GTK2 but there is a lot more underneath(glib...) and on top of it (webkitgtk...) that SWT uses/depends on and it's a matter of time before GTK becomes unusable. This is not smth that SWT developers can do much about. Also my personal attitude about it doesn't say that it should prevent people from fixing GTK 2 related issues - they are more than welcome and I would surely review such patches if/when they appear.
(In reply to Andrey Loskutov from comment #65) > (In reply to Ortwin Glück from comment #63) > +1 > By all respect to the tremendous efforts of the RH team to bring GTK3 port > to a usable state, I still can't use it and would not recommend to use it to > anyone in production environment (based on my personal experience on Fedora > 21/RHEL7 and my observations about bugs coming in to the platform tracker). What do you mean are the most important bugs? I believe applying the patch for bug 467499 would significantly improve GTK3. There are eight duplicates of this bug.
(In reply to Snjezana Peco from comment #68) > What do you mean are the most important bugs? > I believe applying the patch for bug 467499 would significantly improve > GTK3. > There are eight duplicates of this bug. Yep. This is the first one which came to my mind. Paint artefacts / wrong line numbers in editor is a "no go". The second one (more a matter of taste one would say) is bug 456345 (which was "fixed") - the "huge toolbars" on GTK3. I haven't time yet to compare/verify the current state, but I believe the main toolbar & min/max buttons for views are still bigger on GTK3 last time I tried GTK3 port. I must confess, I start GTK3 version once per milestone build in the hope it is useful but usually I simply give up in few minutes and go back to GTK2, therefore I cannot say what is most important *right now*.
Dogfood your work. Try and do actual development under GTK3. You realize quickly what's important.
(In reply to Ortwin Glück from comment #70) > Dogfood your work. Try and do actual development under GTK3. You realize > quickly what's important. When you're developing something, it's not easy to get an idea of the priority of the tasks. As expert of the code, you develop workarounds and get used to incomplete or bad state, so you can loose synchronization on the priority and perceived quality by other users. I agree dogfooding is a requirement, but it's not always enough to identify the most important bugs. For that, the user feedback is always the best source possible, especially for the experts of the domain. So when you're asked what are the top priorities by a developer, it's nice to actually share what you perceive as the top priorities; they didn't ask it without reason and if they did so, it's because it's helpful for them. As of my top 2 annoying issues for GTK3: 1. bug 467499 2. bug 485906 I'm using Eclipse on GTK3 (Fedora 23, Gnome and recent GTK3 version) daily; and to me, they are the 2 only issues remaining compared to GTK2.
This is how Mars-2 looks for me: https://odi.ch/weblog/posting.php?posting=698
(In reply to Ortwin Glück from comment #70) > Dogfood your work. Try and do actual development under GTK3. You realize > quickly what's important. +1 Please also give other SWT-based applications a try that you might integrate in your work-flow, e.g. SmartGit. On a plain Ubuntu 14.04, for example, setting SWT_GTK3 to 1 quickly causes hard crashes. What would be more important for me is why this specific hang occurs with the latest SmartGit and not with previous versions. I've tried a lot of Linux variants and could not reproduce it myself (with SWT_GTK3=0). Does anybody has some clues what could cause this hang? I want be able to reproduce it myself and try to find a quick work-around (SWT_GTK=1 is no option right now).
(In reply to Thomas Singer from comment #73) > (In reply to Ortwin Glück from comment #70) > > Dogfood your work. Try and do actual development under GTK3. You realize > > quickly what's important. > > +1 > > Please also give other SWT-based applications a try that you might integrate > in your work-flow, e.g. SmartGit. On a plain Ubuntu 14.04, for example, > setting SWT_GTK3 to 1 quickly causes hard crashes. Is there a bugzilla for that?
(In reply to Ortwin Glück from comment #72) > This is how Mars-2 looks for me: > https://odi.ch/weblog/posting.php?posting=698 https://akurtakov.fedorapeople.org/screenshot.png - for the sake of reference - this is how Eclipse looks for me - Neon nightly, Fedora 23. Not as bad you see it, right? There are many issues people face with different GTK themes (well, known issue) and this requires a lot more manpower to get right than we currently have. And dogfooding is not enough when speak about theming issues - there are hundreds of theme combinations - each with it's oddities. Btw, do you see it in the same broken way with Neon?
(In reply to Mickael Istria from comment #71) > 2. bug 485906 I think Eric has fixed this bug.
*** Bug 490478 has been marked as a duplicate of this bug. ***
I had a UI freeze as exactly as described in this report. Eclipse 4.6. So this old bug is still a problem. Stackdump shows a trace similar as attached in original report, albeit the line numbers are a bit different. I'll paste it in case its useful. In my case it happened while moving mouse with CTRL key held down (which makes sense as it is a call from 'MultipleHyperlinkPresenter'. "main" #1 prio=6 os_prio=0 tid=0x00007f304c00a000 nid=0x25c0 runnable [0x00007f3053127000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2495) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2399) at org.eclipse.jface.text.AbstractInformationControl.setVisible(AbstractInformationControl.java:513) at org.eclipse.jface.text.AbstractInformationControlManager.showInformationControl(AbstractInformationControlManager.java:1283) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.showInformationControl(MultipleHyperlinkPresenter.java:607) at org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(AbstractInformationControlManager.java:1234) at org.eclipse.jface.text.AbstractInformationControlManager.presentInformation(AbstractInformationControlManager.java:1163) at org.eclipse.jface.text.AbstractInformationControlManager.setInformation(AbstractInformationControlManager.java:428) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.computeInformation(MultipleHyperlinkPresenter.java:588) at org.eclipse.jface.text.AbstractInformationControlManager.doShowInformation(AbstractInformationControlManager.java:1144) at org.eclipse.jface.text.AbstractInformationControlManager.showInformation(AbstractInformationControlManager.java:1134) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter.showHyperlinks(MultipleHyperlinkPresenter.java:788) at org.eclipse.jface.text.hyperlink.HyperlinkManager.showHyperlinks(HyperlinkManager.java:554) at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:456) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:213) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5219) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4553) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4143) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:687) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:604) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610) at org.eclipse.equinox.launcher.Main.run(Main.java:1519) at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Something that helped me a quite a lot is to remap the keyboard shortcut from ctrl to something less-frequently-pressed in general development (for example, ctrl is pressed every time I copy-paste, resulting in oh-so-many invocations of this popup). I remapped it to ctrl+alt and only got the freeze a couple of times since. It's not a fix or a complete workaround, but it helps. (In reply to Kris De Volder from comment #78) > I had a UI freeze as exactly as described in this report. Eclipse 4.6. So > this old bug is still a problem. > ...
*** Bug 361341 has been marked as a duplicate of this bug. ***
@Eric Williams That bug doesn't look like a duplicate of this one. This one is a hang and the other is a JVM crash. Also the crashlog doesn't have a stack that looks similar to the ones in this bug. Did you perhaps want flag it as a duplicate of some other bug and got some bug-numbers mixed up?
(In reply to Kris De Volder from comment #81) > @Eric Williams That bug doesn't look like a duplicate of this one. This one > is a hang and the other is a JVM crash. Also the crashlog doesn't have a > stack that looks similar to the ones in this bug. Did you perhaps want flag > it as a duplicate of some other bug and got some bug-numbers mixed up? My mistake. I was under the impression that this bug also covered crashes in g_main_context_iteration(). I'll remove the duplicate.
I've had another report from a user in our company that they are hitting this bug on Ubuntu 16.04 (I'm hitting it on 14.04).
We just finished collecting data for freeze reports within Google and have discovered some data relevant to this bug. Our methodology: We gathered freeze reports from a large number of machines (several hundred running a 4.7 build and several thousand running a 4.6 build). Then we walked every sample from every freeze report. We collected all the stack frames that were present in each sample and multiplied by D/n (where D is the freeze duration and n is the number of samples). Frames that were present more than once (such as recursive methods) were only counted once. We then added up the totals, which gave us an estimate of the cumulative duration that each stack frame was present during freezes across all those machines. On Eclipse 4.6, we saw this: org.eclipse.swt.widgets.Shell.setVisible:2399 67.71% org.eclipse.swt.internal.gtk.OS.g_main_context_iteration:2495 77.95% On Eclipse 4.7, we saw this: Shell.setVisible was not present in the top 1000 frames. org.eclipse.swt.internal.gtk.OS.g_main_context_iteration:2106 36.24% Both data sets were collected over the same time period using the GTK2 variant of SWT. We also saw a big increase in the percentages (between 3-5 times) for almost everything else in 4.7. Here is one possible hypothesis that is consistent with this data: On Eclipse 4.6, 67% of the freeze time was caused by setVisible calling g_main_context_iteration. 10% of the freeze time was caused by other callers of g_main_context_iteration. The setVisible freezes were fixed in 4.7, which addressed 67% of the freezes and made the percentages for every other freeze jump by about 3 times. The remaining freezes in g_main_context_iteration are still present in 4.7, but it now shows up as 36.24% rather than 10% since the fix to setVisible caused an expected 3x proportional increase elsewhere (the remaining 6% could have been caused by a combination of statistical error and unrelated performance fixes also increasing the relative percentages). If this is the case, it predicts the following for 4.7 builds: - This bug is significantly better now. - We should see very few (if any) freezes involving setVisible. - We should see a significant decrease in g_main_context_iteration freezes, and almost all of them should have other callers. What I don't understand is WHY this appears to have changed. I can't find any commits in the SWT repository that would explain why the setVisible-related freezes would have been reduced (which - admittedly - is a pretty strong argument against my hypothesis).
Note that our data shows this is the single biggest cause of freezes on both 4.6 and 4.7. It just shows that setVisible isn't present on the stacks in 4.7. It also suggests that the cumulative freeze duration may be significantly better on 4.7. Note that this isn't the only possible interpretation of the data. It's also possible that there have been a number of unrelated performance regressions on 4.7 that are just causing g_main_context_iteration to take up a smaller overall percentage of the freeze duration.
(In reply to Stefan Xenos from comment #84) > Both data sets were collected over the same time period using the GTK2 > variant of SWT. > Does it mean that only people running GTK2 aka SWT_GTK3=0 experience this issue and people with GTK 3 do not ?
> Does it mean that only people running GTK2 aka SWT_GTK3=0 experience > this issue and people with GTK 3 do not ? Not quite. We didn't test any users that use GTK3. Everyone we tested was on GTK2. What it means is that - amongst our test participants, the users (around 300 of them) running Eclipse 4.7 did not see a high incidence of Shell.setVisible in freeze reports over the past 30 days. The users running Eclipse 3.6 saw a very high incidence of such reports. Also, I should clarify comment 84. When I say that g_main_context_iteration was on 36.24% of freeze reports, that doesn't mean it was responsible for the freeze. It just means it was present on some stack frame. There could have been something else higher up the stack which was responsible (we aren't distinguishing these cases yet).
I'm on GTK3 and freezes up for me quite frequently, sometimes more than once a day. Little question on the 'methodology'. You say this: > where D is the freeze duration and n is the number of samples My impression is that the duration 'D' is infinite. In other words its like a 'deadlock'. When it hits the freeze you could wait as long as you like, it just won't ever come out of it. Of course I don't sit around forever but usually end up killing Eclipse after a minute or two. How would such a freeze be counted? You'd just count the time until I killed Eclipse I suppose?
> How would such a freeze be counted? You'd just count the time until I > killed Eclipse I suppose? You weren't in our study because we only ran it internally within our company. We used the standard Eclipse responsiveness monitoring tool to collect the data, which has deadlock detection. After 300 seconds it reports the freeze as a deadlock. Anyone who killed Eclipse prior to that timeout would not have had anything collected. Anyone who killed it afterward, would have it reported as a deadlock and the relevant stack frames would be tagged as taking 300 seconds. Is there anyone running 4.7 that is still seeing this?
(In reply to Stefan Xenos from comment #89) > Is there anyone running 4.7 that is still seeing this? I can't recall having seen this particular freeze ever since comment 17. At least no recently (using oxygen builds).
(In reply to Kris De Volder from comment #88) > I'm on GTK3 and freezes up for me quite frequently, sometimes more than once > a day. > > Little question on the 'methodology'. You say this: > > > where D is the freeze duration and n is the number of samples > > My impression is that the duration 'D' is infinite. In other words its like > a 'deadlock'. When it hits the freeze you could wait as long as you like, it > just won't ever come out of it. Of course I don't sit around forever but > usually end up killing Eclipse after a minute or two. How would such a > freeze be counted? You'd just count the time until I killed Eclipse I > suppose? There was a deadlock in the past if you were using eclipse with webkit2. But I fixed that one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=512001 If there are further deadlocks, a report on how to reproduce and/or stacktrace would be beneficial.
*** Bug 514584 has been marked as a duplicate of this bug. ***
Based on my findings, I'd suggest we mark this as fixed and reopen it if and when someone sees this occur in a 4.7 build post-M6. I have no idea what fixed it, but the fact that these reports all seem to be for 4.6 suggest that it is, in fact, fixed.
This is **not** fixed at all. I am getting this still on an almost daily basis with a very similar stacktrace. This is with Eclipse Oxygen on Ubuntu 16.04, running with GTK3. The symptoms are identical to what I reported before. It tends to happen when I have the CTRL key held down while moving the mouse around, and call seems to originitate from the code that's trying to show a little popup with 'hyperlinks'. There is a popup without any content visible on screen and then the ui freezes up completely leaving as only option to kill Eclipse process. Stacktrace collected during hang with jstack: "main" #1 prio=6 os_prio=0 tid=0x00007fa32000a000 nid=0x4a43 runnable [0x00007fa327089000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2110) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2431) at org.eclipse.jface.text.AbstractInformationControl.setVisible(AbstractInformationControl.java:514) at org.eclipse.jface.text.AbstractInformationControlManager.showInformationControl(AbstractInformationControlManager.java:1281) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.showInformationControl(MultipleHyperlinkPresenter.java:607) at org.eclipse.jface.text.AbstractInformationControlManager.internalShowInformationControl(AbstractInformationControlManager.java:1232) at org.eclipse.jface.text.AbstractInformationControlManager.presentInformation(AbstractInformationControlManager.java:1161) at org.eclipse.jface.text.AbstractInformationControlManager.setInformation(AbstractInformationControlManager.java:428) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter$MultipleHyperlinkHoverManager.computeInformation(MultipleHyperlinkPresenter.java:588) at org.eclipse.jface.text.AbstractInformationControlManager.doShowInformation(AbstractInformationControlManager.java:1142) at org.eclipse.jface.text.AbstractInformationControlManager.showInformation(AbstractInformationControlManager.java:1132) at org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter.showHyperlinks(MultipleHyperlinkPresenter.java:788) at org.eclipse.jface.text.hyperlink.HyperlinkManager.showHyperlinks(HyperlinkManager.java:553) at org.eclipse.jface.text.hyperlink.HyperlinkManager.mouseMove(HyperlinkManager.java:455) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:213) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5252) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1348) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4522) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4107) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1044) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680) at org.eclipse.ui.internal.Workbench$$Lambda$70/1356806123.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) at org.eclipse.equinox.launcher.Main.run(Main.java:1499) at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
I run into this frequently when running Eclipse Oxygen on Ubuntu 16.04. Same behavior and stack trace as described in the previous comment. I've also reproduced this from Ubuntu 16.04 on WSL.
(In reply to Kris De Volder from comment #94) > The symptoms are identical to what I reported before. It tends to happen > when I have the CTRL key held down while moving the mouse around, and call > seems to originitate from the code that's trying to show a little popup with > 'hyperlinks'. There is a popup without any content visible on screen and > then the ui freezes up completely leaving as only option to kill Eclipse > process. I frequently see some "empty" popup "stick to the glass", i.e., when I move the Eclipse window, this area still shows the pixels of the Eclipse window at its previous position. Does that match you observation, too? For me this bug also "works" for menus in some situation (under unknown conditions).
I gave up with Eclipse on Oxygen GTK theme. For years now I have been using the Clearlooks GTK theme for GTK2 (env SWT_GTK3=0) and the hangs went away.
> I frequently see some "empty" popup "stick to the glass", i.e., when I move the Eclipse window, this area still shows the pixels of the Eclipse window at its previous position. Not exactly, the popup is empty, yes, but its not transparant but just a empty, opaque, rectangle. Not sure if that's significant, it could depend on OS themes or whatnot. Switching off GTK3 may be an option, I used to do that, but stopped maybe about a year ago when I felt like SWT on GTK2 was starting to feel (even) more buggy and glitchy than GTK3.
BTW this bug is 'sort of reproducible' for me. I can pretty reliably trigger it just by doing this: Open the code I'm working on and frantically drag the mouse around the code while hammering the CTRL-key. So that you see the 'Open Declaration / Open Implementation' popup appear repeatedly in different places. Continually holding down the CTRL key doesn't seem to be as 'successful' as pressing and releasing it rapidly. Also I tried it with a very simple project I could attach and write up detailed steps to reproduce, but alas, with the simple project I couldn't seem to reproduce it. Also sometimes it can take quite a lot of time before I get 'lucky'. That's why I said its 'sort of reproducible'. Still, maybe someone else could reproduce it like this and might then have a chance to debug it.
Created attachment 270054 [details] gdb stack traces "thread apply all bt" Main thread on top: #0 0x00007fa0a8b7ec5d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f9f529d2fe4 in g_main_context_poll (priority=2147483647, n_fds=3, fds=0x7fa0a03697d0, timeout=0, context=0x7fa0a035ec60) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:4028 #2 g_main_context_iterate (context=context@entry=0x7fa0a035ec60, block=block@entry=0, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3729 #3 0x00007f9f529d30ec in g_main_context_iteration (context=0x7fa0a035ec60, may_block=0) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795 #4 0x00007f9f40bce80c in Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration () from /home/dfriederich/eclipse/java/eclipse/configuration/org.eclipse.osgi/702/0/.cp/libswt-pi3
I haven't read the whole thing, but content assist (as seen by stacktrace) uses webkit. Webkit1 is somewhat unstable. Have you guys tried running webkit2? export SWT_WEBKIT2=1 export SWT_LIB_VERSIONS=1 #This should print webkit version in console. ./eclipse Any improvements?
> Have you guys tried running webkit2? > export SWT_WEBKIT2=1 > export SWT_LIB_VERSIONS=1 #This should print webkit version in console. > ./eclipse > > Any improvements? I did locally set SWT_WEBKIT2=1 and did not see a hang since. But of course that does not profs it fixes the issue, just hints into that direction. I did set the env var 2 days ago after a series of hangs, since then I did not experience the issue yet. So far I would say it helps :-)
(In reply to Leo Ufimtsev from comment #101) > Have you guys tried running webkit2? > > export SWT_WEBKIT2=1 I've set this variable about a week and a half ago after I first read your comment. When I check Installation Details I see these two set: org.eclipse.swt.internal.gtk.version=3.18.9 org.eclipse.swt.internal.webkitgtk.version=2.16.6 3.18.9 matches the version of libgtk-3-0 package in my Ubuntu. 2.16.6 matches the version of the libwebkit2gtk package in my Ubuntu. After making this change, things that use the embedded browser still appear to work. However, I'm still seeing Oxygen hanging randomly when pressing CTRL key, same stuck thread as previously described in comment 94. So, this definitely didn't solve anything for me in my environment and unclear how much it helped.
(In reply to Joseph Benken from comment #103) > (In reply to Leo Ufimtsev from comment #101) > > Have you guys tried running webkit2? > > > > export SWT_WEBKIT2=1 > > I've set this variable about a week and a half ago after I first read your > comment. When I check Installation Details I see these two set: > org.eclipse.swt.internal.gtk.version=3.18.9 > org.eclipse.swt.internal.webkitgtk.version=2.16.6 > > 3.18.9 matches the version of libgtk-3-0 package in my Ubuntu. > 2.16.6 matches the version of the libwebkit2gtk package in my Ubuntu. > > After making this change, things that use the embedded browser still appear > to work. However, I'm still seeing Oxygen hanging randomly when pressing > CTRL key, same stuck thread as previously described in comment 94. So, this > definitely didn't solve anything for me in my environment and unclear how > much it helped. If you're using an older Eclipse, you might have to update to the newest one first. One of the Webkit2 versions used to hang and I fixed it a few months ago. I also fixed another issue related to setVisible() (Bug 465280) a few months ago which caused hangs/freezes. But then again it's certainly possible that the root cause is else where. Would be worth to at least trying out newer eclipse version to see if there's any difference. To download recent nightly/integration builds, please go here: http://download.eclipse.org/eclipse/downloads/ - Scroll down to "4.x Integration Builds". - Click on the most recent stable build like "I201XXXXX...", - Find your platform in the "Eclipse SDK". Download the archive, extract it and run the 'eclipse' binary.
(In reply to Leo Ufimtsev from comment #104) > If you're using an older Eclipse, you might have to update to the newest one > first. One of the Webkit2 versions used to hang and I fixed it a few months > ago. I also fixed another issue related to setVisible() (Bug 465280) a few > months ago which caused hangs/freezes. Thanks. I upgraded from 4.7.0 to 4.7.1RC4. I haven't been able to get the hang to reproduce, hovering over method invocations and pressing CTRL while trying to click or move the mouse. From my perspective, the issue is either fixed or at least difficult to reproduce.
(In reply to Joseph Benken from comment #105) > Thanks. I upgraded from 4.7.0 to 4.7.1RC4. I haven't been able to get the I was talking more like 4.8 builds, as 4.7 only contains very early webkit2 work, not all the newest fixes. But if it works... Let's keep an eye on things. I think once webkit2 port is complete and eclipse is fully switched over to use webkit2 as default and the issue doesn't occur there, then we're good. I've liked the webkit2 port in 'see also'.
(In reply to Leo Ufimtsev from comment #106) > I was talking more like 4.8 builds, as 4.7 only contains very early webkit2 > work, not all the newest fixes. But if it works... Thank you for clarifying that 4.8 has additional webkit fixes. Before taking the plunge to 4.8 I wanted to try 4.7.1 first, seeing at least one of the fixes was backported. > Let's keep an eye on things. I think once webkit2 port is complete and > eclipse is fully switched over to use webkit2 as default and the issue > doesn't occur there, then we're good. I've liked the webkit2 port in 'see > also'. Sounds good. Personally, I'm pretty happy at this point. Oxygen no longer seems to hang on me anymore. This was the only real pain I had when switching from Windows to Linux GTK. Having to kill and restart my Eclipse once or twice a day (unless I was really careful when pressing CTRL key over method and field names) had been very annoying and painful.
~ I'm doing some bugzilla spring cleaning/Triaging. Based on bug report and stack trace: at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2258) at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2051) This is a duplicate of: 509587 – (webkit1JvmCrashes) [Browser][Webkit 1] JVM crashes tracking bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=509587 I.e, an issue that only occurs in Webkit1. (Please see above bug for details) Note, as of 4.8 M5, webkit2 is default. People who experience this issue should consider updating to 4.8 M5 when possible or wait for full 4.8 release: http://download.eclipse.org/eclipse/downloads/ Closing as duplicate for now. (The other bug is shorter and a bit easier for incoming users to read). If this is not the case, please kindly re-open and explain. Thank you for your time and bug submissions! *** This bug has been marked as a duplicate of bug 509587 ***
If issue still occurs with 4.8 M5+ & Webkit2, please reopen. Btw, this might not be very obvious from initial observation, setVisibility() usually breaks webkit1, and I see from stacktraces webkit1 was used in some part of ui, e.g "BrowserInformationControl" in: org.eclipse.jface.internal.text.html.BrowserInformationControl.setVisible(BrowserInformationControl.java:367) So all these usually trace back to webkit1 in some way or another. It's been the source of a lot of trouble for us. Please let us know if we can further help. Thanks!
*** Bug 492899 has been marked as a duplicate of this bug. ***
*** Bug 480290 has been marked as a duplicate of this bug. ***
*** Bug 491322 has been marked as a duplicate of this bug. ***
i am getting reports on Eclipse 4.10 that it hangs on: Thread: main, state: RUNNABLE, total cpu time: 25917.09418ms, total user time: 24320.0ms org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1581) org.eclipse.swt.browser.WebKit$Webkit2AsyncToSync.execAsyncAndWaitForReturn(WebKit.java:1892) org.eclipse.swt.browser.WebKit$Webkit2AsyncToSync.runjavascript(WebKit.java:1794) org.eclipse.swt.browser.WebKit$Webkit2AsyncToSync.evaluate(WebKit.java:1742) org.eclipse.swt.browser.WebKit.evaluate(WebKit.java:1928) org.eclipse.swt.browser.WebKit.close(WebKit.java:1549) org.eclipse.swt.browser.WebKit.onDispose(WebKit.java:2556) org.eclipse.swt.browser.WebKit.lambda$4(WebKit.java:1310) org.eclipse.swt.browser.WebKit$$Lambda$469/976236749.handleEvent(Unknown Source) org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) org.eclipse.swt.widgets.Display.sendEvent(Display.java:5663) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1386) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1391) org.eclipse.swt.widgets.Widget.release(Widget.java:1203) org.eclipse.swt.widgets.Control.release(Control.java:4164) org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1447) org.eclipse.swt.widgets.Widget.release(Widget.java:1206) org.eclipse.swt.widgets.Control.release(Control.java:4164) org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1447) org.eclipse.swt.widgets.Canvas.releaseChildren(Canvas.java:279) org.eclipse.swt.widgets.Decorations.releaseChildren(Decorations.java:486) org.eclipse.swt.widgets.Shell.releaseChildren(Shell.java:2970) org.eclipse.swt.widgets.Widget.release(Widget.java:1206) org.eclipse.swt.widgets.Control.release(Control.java:4164) org.eclipse.swt.widgets.Widget.dispose(Widget.java:522) org.eclipse.swt.widgets.Shell.dispose(Shell.java:2897) org.eclipse.jface.window.ToolTip.toolTipHide(ToolTip.java:438) org.eclipse.jface.window.ToolTip.access$1(ToolTip.java:433) org.eclipse.jface.window.ToolTip$ToolTipOwnerControlListener.handleEvent(ToolTip.java:606) org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) org.eclipse.swt.widgets.Display.sendEvent(Display.java:5663) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1386) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412) org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1395) org.eclipse.swt.widgets.Control.sendOrPost(Control.java:4483) org.eclipse.swt.widgets.Control.sendMouseEvent(Control.java:4474) org.eclipse.swt.widgets.Control.gtk_scroll_event(Control.java:3754) org.eclipse.swt.widgets.Scrollable.gtk_scroll_event(Scrollable.java:306) org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1971) org.eclipse.swt.widgets.Control.windowProc(Control.java:6298) org.eclipse.swt.widgets.Tree.windowProc(Tree.java:3995) org.eclipse.swt.widgets.Display.windowProc(Display.java:5880) org.eclipse.swt.internal.gtk.GTK._gtk_main_do_event(Native Method) org.eclipse.swt.internal.gtk.GTK.gtk_main_do_event(GTK.java:3969) org.eclipse.swt.widgets.Display.eventProc(Display.java:1385) org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1581) org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4470) org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173) that looks a lot the same but is not directly related to setVisible..
