Bug 370215 - [GTK3][webkit?] Freeze and 100% load while showing hovers
Summary: [GTK3][webkit?] Freeze and 100% load while showing hovers
Status: CLOSED DUPLICATE of bug 509587
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.2   Edit
Hardware: Other Linux
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 527444
  Show dependency tree
 
Reported: 2012-01-31 08:53 EST by Stephan Herrmann CLA
Modified: 2019-03-26 15:15 EDT (History)
8 users (show)

See Also:


Attachments
stack when it froze (25.44 KB, text/plain)
2012-01-31 08:53 EST, Stephan Herrmann CLA
no flags Details
stack shortly after (22.31 KB, text/plain)
2012-01-31 08:55 EST, Stephan Herrmann CLA
no flags Details
after killing the application being debugged (16.76 KB, text/plain)
2012-01-31 08:56 EST, Stephan Herrmann CLA
no flags Details
The part of the compare editor outside of "busy" Eclipse (727.08 KB, image/png)
2017-11-18 09:10 EST, Andrey Loskutov CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2012-01-31 08:53:38 EST
Created attachment 210311 [details]
stack when it froze

Build id: I20120127-1145 aka SDK 4.2 M5 

Kubuntu 11.04 with libgtk-3-0 3.0.8-0ubuntu1

OpenJDK Runtime Environment (IcedTea6 1.10.4) (6b22-1.10.4-0ubuntu1~11.04.2)
OpenJDK Server VM (build 20.0-b11, mixed mode)

During a debug session a JDT hover appeared and at that point Eclipse stopped reacting to any input.


I took three stack dumps:

1. when the problem occured
2. a couple of minutes later
3. after killing the application being debugged

In all stack dumps you'll see the typical

"main" prio=10 tid=0x08864c00 nid=0x3323 runnable [0xbfb49000]
   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:2310)
	at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2057)
	at org.eclipse.jface.text.AbstractInformationControl.setVisible(AbstractInformationControl.java:505)

The only change I could see in this thread: the hash-ID of the lock further down the stack changed, but I assume this doesn't mean the object actually changed, no?

I seem to remember some freeze was fixed as of JRE 1.7? I couldn't find the bug right now. 

I just forgot to set -vm for this install as I usually do.
Comment 1 Stephan Herrmann CLA 2012-01-31 08:55:01 EST
Created attachment 210312 [details]
stack shortly after

This stack shows only irrelevant changes (?)
Comment 2 Stephan Herrmann CLA 2012-01-31 08:56:45 EST
Created attachment 210313 [details]
after killing the application being debugged

Killing the application being debugged caused some activity, but didn't unfreeze it.
Comment 3 Andrey Loskutov CLA 2017-04-12 07:20:38 EDT
Same here on 4.6.3 / KDE / GTK 3.0.

Looks like "help tooltips" sometime hang while showing up, causing entire Eclipse UI to hang. Eclipse does not freeze in classical sense (all repaints are there) but no interaction with the UI is possible anymore (no effect). The rectangle area for the "to be shown popup" is filled with some visual garbage, can't be moved or closed and stays on the screen until Eclipse is killed.

"main" prio=10 tid=0x08864c00 nid=0x3323 runnable [0xbfb49000]
   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:2310)
	at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2057)
	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)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
	- locked <0x52c029a8> (a org.eclipse.swt.widgets.RunnableLock)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3510)
Comment 4 Leo Ufimtsev CLA 2017-04-13 09:28:10 EDT
1) Steps to reproduce:
Can you explain which debug hover causes the hang? Screenshot would be great.
(there are different hovers..).
Do you mean when you hover over a variable and it's suppose to show it's value?

Does it reproduce all the time or only once in a while?

2) Build:
(In reply to Stephan Herrmann from comment #0)
> Build id: I20120127-1145 aka SDK 4.2 M5 

This is a very old build. It's unlikely to be investigated. 2012?
Does the issue occur with a newer build?
http://download.eclipse.org/eclipse/downloads/drops4/I20170412-2000/download.php?dropFile=eclipse-SDK-I20170412-2000-linux-gtk-x86_64.tar.gz

the setVisible() method is notorious for causing hangs/freezes, it contains a context_iteration(). But it's not exactly clear why the issue occurs. But there's been a number of fixes related to it in newer builds already. So we try to investigate any new issues on newer builds.

3) Does the hang occur on gtk?
export SWT_GTK3=0
./eclipse

This could help us investigate if it's a gtk3 specific thing or maybe a generic logic bug.
Comment 5 Stephan Herrmann CLA 2017-04-13 09:40:53 EDT
(In reply to Leo Ufimtsev from comment #4)
> 2) Build:
> (In reply to Stephan Herrmann from comment #0)
> > Build id: I20120127-1145 aka SDK 4.2 M5 
> 
> This is a very old build. It's unlikely to be investigated. 2012?

It was brand new (4 days) when I reported this bug :D

> Does the issue occur with a newer build?

I haven't seen it recently.
Comment 6 Andrey Loskutov CLA 2017-04-13 09:56:01 EDT
(In reply to Leo Ufimtsev from comment #4)
> 1) Steps to reproduce:
> Can you explain which debug hover causes the hang? Screenshot would be great.
> (there are different hovers..).
> Do you mean when you hover over a variable and it's suppose to show it's
> value?

We get this just for "usual" JDT javadoc hovers shown over the methods or types

> Does it reproduce all the time or only once in a while?

Seldom, I would say ~ once per two weeks or so, and we have no idea how to reproduce.

> 2) Build:
> (In reply to Stephan Herrmann from comment #0)
> > Build id: I20120127-1145 aka SDK 4.2 M5 
> 
> This is a very old build. It's unlikely to be investigated. 2012?
> Does the issue occur with a newer build?

We observe this on a 4.6.3 build.

> the setVisible() method is notorious for causing hangs/freezes, it contains
> a context_iteration(). But it's not exactly clear why the issue occurs. But
> there's been a number of fixes related to it in newer builds already. So we
> try to investigate any new issues on newer builds.
> 
> 3) Does the hang occur on gtk?
> export SWT_GTK3=0
> ./eclipse

Since this happens for different users, and they want to use Eclipse for they daily work, I can't say them they should do this because with GTK2 we will get no nice javadoc support anymore on RHEL 7.2 (no gtk2 browser).
Comment 7 Leo Ufimtsev CLA 2017-04-13 10:12:53 EDT
(In reply to Stephan Herrmann from comment #5)
> (In reply to Leo Ufimtsev from comment #4)
> > 2) Build:
> > (In reply to Stephan Herrmann from comment #0)
> > > Build id: I20120127-1145 aka SDK 4.2 M5 
> > 
> > This is a very old build. It's unlikely to be investigated. 2012?
> 
> It was brand new (4 days) when I reported this bug :D

:-D :-D. I didn't pay attention to report date. My bad. Quite entertaining.

> > Does the issue occur with a newer build?
> 
> I haven't seen it recently.


(In reply to Andrey Loskutov from comment #6)
> Since this happens for different users, and they want to use Eclipse for
> they daily work, I can't say them they should do this because with GTK2 we
> will get no nice javadoc support anymore on RHEL 7.2 (no gtk2 browser).

I'm pretty sure there's a deadlock in webkit1 somewhere. What happens I think:
1) Webkit1 does something very important.
2) Webkit1 get's interrupted by gtk
3) Gtk does stuff, calls SWT which reaches setVisible() wich calls context_iteration()
4) Context iteration messes with event ordering, (which impacts webkit1's logic)
5) Webkit1 resumes, but due to some logic flaw, it's waiting for an event that's already been processed by context_iteration() above. It hangs.

Often webkit1 will crash in setVisible() also. In general webkit1 is somewhat unreliable in combination with context_iteration().

Hmmm. Do you guys have webkit2 on your systems? Webkit2 runs in it's own process with much better isolation. So context_iteration() has less of an impact on it.

The hovers use webkit underneath, maybe with webkit2 the freezes don't occur since it works somewhat different and I know for a fact that webkit is very quirky with the setVisible() method in shell because of the context_iteration call.

To tell:
sudo dnf(or yum) list installed | grep webkit
webkitgtk4.x86_64  <<< this is the guy you want.

webkitgtk3. is Webkit1 & gtk3
webkitgtk   is webkit1 & gtk2

if not, can you install webkitgtk4?

If yes, can you try eclipse with webkit2?
export SWT_WEBKIT2=1
eclipse

But note, you have to be running latest nightlies (or at least latest milestone) for relevant webkit2 patches, otherwise eclipse won't be very functional.
Comment 8 Stephan Herrmann CLA 2017-06-16 17:20:54 EDT
Exact same symptoms as comment 3 occurred several times over the last days.

Each time lost the last edits (and the context of my Eclipse session).

Here's a stack:

"main" #1 prio=6 os_prio=0 tid=0x00007f43a400a000 nid=0x818 runnable [0x00007f43ac955000]
   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:515)
        at org.eclipse.jdt.internal.ui.text.java.hover.AbstractAnnotationHover$AnnotationInformationControl.setVisible(AbstractAnnotationHover.java:220)
        at org.eclipse.jface.text.AbstractInformationControlManager.showInformationControl(AbstractInformationControlManager.java:1281)
        at org.eclipse.jface.text.TextViewerHoverManager.showInformationControl(TextViewerHoverManager.java:285)
        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.AbstractHoverInformationControlManager.presentInformation(AbstractHoverInformationControlManager.java:894)
        at org.eclipse.jface.text.TextViewerHoverManager.doPresentInformation(TextViewerHoverManager.java:247)
        at org.eclipse.jface.text.TextViewerHoverManager$5.run(TextViewerHoverManager.java:237)
        at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37)
        at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
        - locked <0x00000000ef3cdc00> (a org.eclipse.swt.widgets.RunnableLock)
        at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4472)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4085)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1146)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1035)
        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/1092619788.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)

In my case the region of the hover actually shows the regular Eclipse content, and this "sticks" to the glass even when switching virtual desktops. Amazing!


Build id: Y20170427-1000
org.eclipse.swt.internal.gtk.version=3.18.9
Kubuntu with
$ dpkg --list |grep webkit
ii  libkdewebkit5                                   4:4.14.16-0ubuntu3.2                       amd64        KDE WebKit Library
ii  libkf5webkit5:amd64                             5.18.0-0ubuntu1                            amd64        KDE Integration for QtWebKit.
ii  libqt5webkit5:amd64                             5.5.1+dfsg-2ubuntu1                        amd64        Web content engine library for Qt
ii  libqtwebkit4:amd64                              2.3.2-0ubuntu11                            amd64        Web content engine library for Qt
ii  libwebkit2gtk-3.0-25:amd64                      2.4.11-0ubuntu0.1                          amd64        WebKit2 API layer for WebKitGTK+
ii  libwebkit2gtk-4.0-37:amd64                      2.16.3-0ubuntu0.16.04.1                    amd64        Web content engine library for GTK+
ii  libwebkit2gtk-4.0-37-gtk2:amd64                 2.16.3-0ubuntu0.16.04.1                    amd64        Web content engine library for GTK+ - GTK+2 plugin process
ii  libwebkitgtk-3.0-common                         2.4.11-0ubuntu0.1                          all          Web content engine library for GTK+ - data files
ii  python-pyqt5.qtwebkit                           5.5.1+dfsg-3ubuntu4                        amd64        Python 2 bindings for Qt5's WebKit module
ii  qml-module-qtwebkit:amd64                       5.5.1+dfsg-2ubuntu1                        amd64        Qt WebKit QML module

Will now set SWT_WEBKIT2=1
Can I check if this is correctly picked up?

Interestingly, copying text from "Installation Details" doesn't work, so I can't search its content...
Comment 9 Leo Ufimtsev CLA 2017-06-19 12:00:27 EDT
(In reply to Stephan Herrmann from comment #8)

> Will now set SWT_WEBKIT2=1
> Can I check if this is correctly picked up?

Hmmm. Not sure about ubuntu, but on fedora you can check libs loaded by a process:

- Make note of pid of Eclipse jps  (or jcmd).
- cd /proc/PID
- cat maps | grep libwebkit

Load Eclipse as usual, note version of libwebkit.
Load eclipse with SWT_WEBKIT=2, note version of libwebkit. If it's newer, then webkit2 was loaded instead of webkit1.
The exact version of webkit & gtk is a bit confusing since some webkit bindings map to gtk2, some to gtk3, some to webkit1 & some to webkit2..

With webkit2, do you observe any difference?
Comment 10 Andrey Loskutov CLA 2017-11-18 09:10:07 EST
Created attachment 271542 [details]
The part of the compare editor outside of "busy" Eclipse

Just some observations from the last time we had this on RHEL 7.2 GTK 3.14, I20170802-2000: we were editing code in compare editor. I just copied some code and wanted to paste it in the different place, and UI froze. The "freeze" was interesting: the screen was re-painting and I was able to see the mouse cursor changing the shape over different UI elements, and Eclipse window was responsible to resize and move, but I could not change the cursor position anymore, neither click anything else or use menu. A part of the compare editor screen where the (not shown) hover should probably appear, was "stick" to one position on the screen, and we observed 100% CPU load by JVM, by the main thread.

We really had an impression that the UI was busy, not frozen. Also last time other developer had this issue, CPU load was at 100% for the JVM process.

Stack:

"main" #1 prio=6 os_prio=0 tid=0x00007ffff000a000 nid=0x72f0 runnable [0x00007ffff7fcf000]
   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:2126)
        at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2433)
        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:5585)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4838)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4419)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
        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$19/1137667747.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)

As usually, we had to kill Eclipse.
Comment 11 Stephan Herrmann CLA 2017-11-18 10:32:54 EST
(In reply to Andrey Loskutov from comment #10)
> Created attachment 271542 [details]
> The part of the compare editor outside of "busy" Eclipse
> 
> ... A part of the
> compare editor screen where the (not shown) hover should probably appear,
> was "stick" to one position on the screen, 

That's exactly what I observe every now and then.

Also menus can create this sticky window area, IIRC I observed it with the run or debug toolbar menus.
Comment 12 Leo Ufimtsev CLA 2017-11-20 15:42:35 EST
Does this happen with recent swt & export SWT_WEBKIT2?
Comment 13 Alexander Kurtakov CLA 2018-01-15 16:23:36 EST
Ping. If noone comments I'll assume no one experiences the issue any more and resolve on the next triage.
Comment 14 Andrey Loskutov CLA 2018-01-15 16:26:03 EST
(In reply to Alexander Kurtakov from comment #13)
> Ping. If noone comments I'll assume no one experiences the issue any more
> and resolve on the next triage.

Sure we still observe this. We just can't switch 4.6.3 on RHEL 7.2 to use never webkit.
Comment 15 Andrey Loskutov CLA 2018-01-30 02:54:59 EST
(In reply to Alexander Kurtakov from comment #13)
> Ping. If noone comments I'll assume no one experiences the issue any more
> and resolve on the next triage.

Just got this bug reported again, with the stack below from 4.7.2 on RHEL 7.2 (GTK 3.14):

"main" #1 prio=6 os_prio=0 tid=0x00007ffff000a000 nid=0x72f0 runnable [0x00007ffff7fcf000]
   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:2126)
        at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2433)
        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:5585)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1363)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4838)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4419)
Comment 16 Andrey Loskutov CLA 2018-01-30 03:04:52 EST
Addition: user got a "cheese" in the rectangle over the editor at the place where the dialog should appear and this cheese was in front of everything on his desktop. The user was able to shut down Eclipse and got the following output on command line:
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Comment 17 Leo Ufimtsev CLA 2018-01-30 09:57:21 EST
Ok, this guy is basically the same as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354842

Copy & pasting my comment  :-)

--------------

~ 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 ***
Comment 18 Rafael Chaves CLA 2019-03-25 13:09:48 EDT
Andrey and Leo - this still happens on Eclipse 4.10 on my system. Does it mean it may not be limited to Webkit1?

This is what I get with SWT_LIB_VERSIONS=1:

SWT_LIB_Gtk:3.18.9 (Dynamic gdbus)
SWT_LIB GDbus firing up. Implementation v1.5

Should I just open a new PR?
Comment 19 Eric Williams CLA 2019-03-25 18:01:43 EDT
(In reply to Rafael Chaves from comment #18)
> Should I just open a new PR?

You have a fix? Or do you mean open a new ticket?
Comment 20 Rafael Chaves CLA 2019-03-25 18:03:55 EDT
Sorry, totally showing my age here, I meant PR as a "Problem Request" (as opposed to Pull Requests), which was how we used to call bugzilla tickets back in the day.
Comment 21 Rafael Chaves CLA 2019-03-25 18:04:33 EDT
Argh, Problem Report, I meant. Must be missing my pills.
Comment 22 Eric Williams CLA 2019-03-26 08:58:45 EDT
(In reply to Rafael Chaves from comment #21)
> Argh, Problem Report, I meant. Must be missing my pills.

That's okay. :) Yes please open another ticket as this one is old. Be sure to include steps to reproduce, as well as OS/GTK3/WebKit info. Thanks!
Comment 23 Rafael Chaves CLA 2019-03-26 15:15:58 EDT
Opened bug 545809 - unfortunately, no reproduction steps at this time.