Bugzilla – Full Text Bug Listing
| Summary: | Freeze at org.eclipse.swt.internal.gtk.OS._gdk_window_get_origin | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mateusz Matela <mateusz.matela> | ||||
| Component: | SWT | Assignee: | Andrey Loskutov <loskutov> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ericwill, loskutov, pagew2000, simeon.danailov.andreev | ||||
| Version: | 4.6 | Keywords: | triaged | ||||
| Target Milestone: | 4.11 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: |
https://git.eclipse.org/r/136291 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9eb0a3a293e8289a75571731dc9d0b4cfadad548 https://git.eclipse.org/r/136295 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8c86bb41bb48ccdb80f6cbe5f1ac5bf47dcd4f9f |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Do you still see this? I do not experience this issue on GTK3.22/Fedora 28/4.8 M7. We are seeing same error with our RCP built with Eclipse 4.6 on CentOS and RedHat. "main" #1 prio=6 os_prio=0 tid=0x00007f41dc008800 nid=0x42ac runnable [0x00007f41e52fa000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._gdk_window_get_origin(Native Method) at org.eclipse.swt.internal.gtk.OS.gdk_window_get_origin(OS.java:5940) at org.eclipse.swt.widgets.Control.toControl(Control.java:1502) at org.eclipse.swt.widgets.Control.toControl(Control.java:1532) at org.eclipse.jface.fieldassist.ControlDecoration.getDecorationRectangle(ControlDecoration.java:1193) at org.eclipse.jface.fieldassist.ControlDecoration.lambda$1(ControlDecoration.java:623) at org.eclipse.jface.fieldassist.ControlDecoration$$Lambda$16/705602706.paintControl(Unknown Source) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:231) 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.Widget.sendEvent(Widget.java:1366) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1349) at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3361) at org.eclipse.swt.widgets.Composite.gtk_draw(Composite.java:367) at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:172) at org.eclipse.swt.widgets.Shell.gtk_draw(Shell.java:1337) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1962) at org.eclipse.swt.widgets.Control.windowProc(Control.java:5819) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5490) 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:9545) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1275) 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.Display.readAndDispatch(Display.java:4141) Is it related to GTK version? If I set SWT_GTK3=0, I don't get this error. Can someone clarify what GTK version should be used? On the RedHat, we have gtk3-3.22.10-5.el7_4.x86_64. On the CentOS, we have gtk3-3.14.13-16.el7.x86_64, and I see this issue on both. Thanks! Thanks. (In reply to Page Wang from comment #2) > We are seeing same error with our RCP built with Eclipse 4.6 on CentOS and > RedHat. > > "main" #1 prio=6 os_prio=0 tid=0x00007f41dc008800 nid=0x42ac runnable > [0x00007f41e52fa000] > java.lang.Thread.State: RUNNABLE > at org.eclipse.swt.internal.gtk.OS._gdk_window_get_origin(Native Method) > at org.eclipse.swt.internal.gtk.OS.gdk_window_get_origin(OS.java:5940) > at org.eclipse.swt.widgets.Control.toControl(Control.java:1502) > at org.eclipse.swt.widgets.Control.toControl(Control.java:1532) > at > org.eclipse.jface.fieldassist.ControlDecoration. > getDecorationRectangle(ControlDecoration.java:1193) > at > org.eclipse.jface.fieldassist.ControlDecoration.lambda$1(ControlDecoration. > java:623) > at > org.eclipse.jface.fieldassist.ControlDecoration$$Lambda$16/705602706. > paintControl(Unknown Source) > at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:231) > 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.Widget.sendEvent(Widget.java:1366) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1349) > at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3361) > at org.eclipse.swt.widgets.Composite.gtk_draw(Composite.java:367) > at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:172) > at org.eclipse.swt.widgets.Shell.gtk_draw(Shell.java:1337) > at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1962) > at org.eclipse.swt.widgets.Control.windowProc(Control.java:5819) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:5490) > 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:9545) > at org.eclipse.swt.widgets.Display.eventProc(Display.java:1275) > 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.Display.readAndDispatch(Display.java:4141) > > > Is it related to GTK version? If I set SWT_GTK3=0, I don't get this error. > > Can someone clarify what GTK version should be used? On the RedHat, we have > gtk3-3.22.10-5.el7_4.x86_64. On the CentOS, we have > gtk3-3.14.13-16.el7.x86_64, and I see this issue on both. > > Thanks! > > Thanks. Do you experience the issue with 4.8? 4.6 is quite old and there have been substantial GTK3 fixes since. As for GTK3 versions, GTK3.22 is the latest and up-to-date GTK3, so that is the one to be used. No response from the original reported in awhile. Please reopen this ticket if the issue still occurs on 4.8 with GTK3.22. Our ARTs ran into something similar, on our branch which bases the product on Eclipse 4.9 SDK.
The test which hangs opens a dialog with JFace WizardDialog (and our own custom wizard). The test hangs at processing UI events after this is done:
"main" #1 prio=6 os_prio=0 tid=0x00007ffff000c800 nid=0x412f runnable [0x00007ffff59f6000]
java.lang.Thread.State: RUNNABLE
at org.eclipse.swt.internal.gtk.GDK._gdk_window_get_origin(Native Method)
at org.eclipse.swt.internal.gtk.GDK.gdk_window_get_origin(GDK.java:2511)
at org.eclipse.swt.widgets.Control.toDisplay(Control.java:1687)
at org.eclipse.jface.fieldassist.ControlDecoration.getDecorationRectangle(ControlDecoration.java:1182)
at org.eclipse.jface.fieldassist.ControlDecoration.lambda$1(ControlDecoration.java:623)
at org.eclipse.jface.fieldassist.ControlDecoration$$Lambda$614/2094159329.paintControl(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5797)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1373)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1399)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1382)
at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3698)
at org.eclipse.swt.widgets.Composite.gtk_draw(Composite.java:436)
at org.eclipse.swt.widgets.Canvas.gtk_draw(Canvas.java:181)
at org.eclipse.swt.widgets.Shell.gtk_draw(Shell.java:1418)
at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1951)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:6524)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:6014)
at org.eclipse.swt.internal.gtk.GTK._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.GTK.gtk_main_do_event(GTK.java:4118)
at org.eclipse.swt.widgets.Display.eventProc(Display.java:1414)
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:1596)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4581)
...
pstack which continues this:
#0 0x00007ffff72c0a3d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fff5b027082 in _xcb_conn_wait (__timeout=-1, __nfds=1, __fds=0x7ffff59f5790) at /usr/include/bits/poll2.h:46
#2 0x00007fff5b027082 in _xcb_conn_wait (c=c@entry=0x7ffff06cae50, cond=cond@entry=0x7ffff59f58b0, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
#3 0x00007fff5b028b9f in wait_for_reply (c=c@entry=0x7ffff06cae50, request=request@entry=17938662, e=e@entry=0x7ffff59f5970) at xcb_in.c:516
#4 0x00007fff5b028d12 in xcb_wait_for_reply64 (c=c@entry=0x7ffff06cae50, request=17938662, e=e@entry=0x7ffff59f5970) at xcb_in.c:560
#5 0x00007fff62abffa0 in _XReply (dpy=dpy@entry=0x7ffff06c9c00, rep=rep@entry=0x7ffff59f59d0, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:596
#6 0x00007fff62abd299 in XTranslateCoordinates (dpy=0x7ffff06c9c00, src_win=494927900, dest_win=616, src_x=0, src_y=23, dst_x=0x7ffff59f5a68, dst_y=0x7ffff59f5a6c, child=0x7ffff59f5a70) at TrCoords.c:51
#7 0x00007fff841c5549 in gdk_window_x11_get_root_coords () at /lib64/libgdk-3.so.0
#8 0x00007fff84198b72 in gdk_window_get_origin () at /lib64/libgdk-3.so.0
...
There is nothing in the IDE jstack that indicates a deadlock or something similar.
We also see a dialog with black client area, grey border, no title and no icons. The IDE in the background looks normal from what I can tell.
GTK+ errors are "normal", plus one that I've not seen so far:
"GtkDialog mapped without a transient parent. This is discouraged."
Coming from gtk/gtkdialog.c:
static void
gtk_dialog_map (GtkWidget *widget)
{
GtkWidget *default_widget, *focus;
GtkWindow *window = GTK_WINDOW (widget);
GtkDialog *dialog = GTK_DIALOG (widget);
if (gtk_window_get_transient_for (window) == NULL)
g_message ("GtkDialog mapped without a transient parent. This is discouraged.");
...
Do note that our Linux environment has some window manager problem at the moment (I'm not very familiar with the topic). So maybe this is a problem in our environment.
Sorry for missing to mention this, we have GTK 3.22.10 in that environment (RHEL 7.4). Seen on 4.9 M3 gtk 3.22 RHEL 7.4. Simeon, any chance you can put together a snippet to reproduce this one? (In reply to Eric Williams from comment #8) > Simeon, any chance you can put together a snippet to reproduce this one? Unfortunately we are clueless as to why this occurs. We have not seen a repetition of the hang ever since upgrading to 4.9 platform. We are running a lot of tests so this must be very sporadic (or maybe even gone). Occurred again yesterday, on our 4.11 branch. 4.11 build was done on a recent integration build tag (not sure exactly which one, something around I20190201-1800). Odd, we'll keep this ticket open to keep track of this issue. Hopefully it becomes more reproducible going forward. The "hang" seem to be "kind of" reproducible now, at least in automated tests. Same test running locally doesn't hang.
Stack (we are at commit 59c8160c4daca04dd486cd8f1e66853a738e5017 build I20190202-1800):
"main" #1 prio=6 os_prio=0 tid=0x00007ffff0051000 nid=0x127d3 runnable [0x00007ffff59bc000]
java.lang.Thread.State: RUNNABLE
at org.eclipse.swt.internal.gtk.GDK._gdk_window_get_origin(Native Method)
at org.eclipse.swt.internal.gtk.GDK.gdk_window_get_origin(GDK.java:2353)
at org.eclipse.swt.widgets.Control.toDisplay(Control.java:1718)
at org.eclipse.jface.fieldassist.ControlDecoration.getDecorationRectangle(ControlDecoration.java:1185)
at org.eclipse.jface.fieldassist.ControlDecoration.lambda$1(ControlDecoration.java:626)
at org.eclipse.jface.fieldassist.ControlDecoration$$Lambda$916/1499382360.paintControl(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5769)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1401)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1427)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1410)
at org.eclipse.swt.widgets.Control.gtk_draw(Control.java:3754)
at org.eclipse.swt.widgets.Composite.gtk_draw(Composite.java:455)
at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2145)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:6645)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:6014)
at org.eclipse.swt.internal.gtk.GTK._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.GTK.gtk_main_do_event(GTK.java:4084)
at org.eclipse.swt.widgets.Display.eventProc(Display.java:1402)
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:1569)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4565)
What wonders me, I see that the call to ControlDecoration.getDecorationRectangle from the paint listener added in in ControlDecoration.addControlListeners() which seem to cause the trouble is actually not needed in most cases, because shouldShowDecoration() returns false in many times:
paintListener = event -> {
Control control = (Control) event.widget;
Rectangle rect = getDecorationRectangle(control);
if (shouldShowDecoration()) {
event.gc.drawImage(getImage(), rect.x, rect.y);
}
};
Changing the order would avoid this call on *probably* hidden widget (we have an in-place tree editor which embeds styled text instance which is not decorated and probably out of the visible area).
I assume we manage to bring the GTK machinery out of order by querying the control state on this embedded editor which seem to be hidden at the moment the query happen. I will push a fix to the ControlDecoration to call getDecorationRectangle() only if it is needed.
OMG. OMFG. I've just put a breakpoint into this paintListener from ControlDecoration. It is called *gazillion* times and it queries getDecorationRectangle() on all the widgets up to the shell starting from the current embedded editor, even if it does not need this AT ALL. Fun: I can't even run debugger with conditional breakpoint in this listener because Eclipse freezes forever trying to evaluate gazillions of the calls here. New Gerrit change created: https://git.eclipse.org/r/136291 Gerrit change https://git.eclipse.org/r/136291 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9eb0a3a293e8289a75571731dc9d0b4cfadad548 New Gerrit change created: https://git.eclipse.org/r/136295 Gerrit change https://git.eclipse.org/r/136295 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8c86bb41bb48ccdb80f6cbe5f1ac5bf47dcd4f9f So was this a Platform UI issue then? (In reply to Eric Williams from comment #18) > So was this a Platform UI issue then? No. It *is* still SWT/GTK issue, which we don't see with 4.10 but observe with 4.11 head. There was also some change in 4.11 which triggered this to appear more often, but I was unable to reproduce the problem with the "isolated" test, it seem to appear only inside a longer automated test suite of our product. *Something* there breaks SWT/GTK at some place, so that one particular test reproducibly hangs with the stack trace I've posted above. But I can't reproduce it manually with this test alone, also not with a subset of tests. At some point in time, if we have some (unknown) precondition, SWT/GTK decides to hang during one of those gazillion paint events. My hope is, that by reducing events number from 1.000.000 to zero (in our case of invisible embedded styled text editor inside a tree), the precondition will not break GTK anymore (in our concrete case). We will see it in few days, I have to wait for next SDK integration build and for our internal build to run the test gain with fixed Platform UI code. The patch you saw for Platform UI helps it be more clever to *avoid* the SWT issue if possible by not doing things which aren't needed at all. Every time a paint event was issued to *any* of the parent widgets of an *invisible* control decoration (up to the top level window shell), Platform UI code asked SWT about this concrete control bounds and did NOT use this data at all!!! I couldn't even count the number of invocations during the test (debugger was busy for minutes just printing hits), but you may imagine how many paint events occur if we have a complex widget hierarchy with a tree table inside a view inside a part stack inside a window and we expand/collapse/scroll the tree. Every single paint inside the window was causing the code in org.eclipse.jface.fieldassist.ControlDecoration.getDecorationRectangle(Control) to run, and the code there issued a number of low level SWT calls via getBounds(), toDisplay(), toControl() etc. (In reply to Eclipse Genie from comment #17) > Gerrit change https://git.eclipse.org/r/136295 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=8c86bb41bb48ccdb80f6cbe5f1ac5bf47dcd4f9f Just verified, that whatever regression we have in SWT 4.11, it is at least not conflicting anymore with *our* code after this commit above. Unfortunately I've failed to create a reproducer :-(. This does not mean, we understood where it was broken, we just do not run into the possibility for a crash now after UI change. *This* bug with hanging OS._gdk_window_get_origin(Native Method) is most likely just a symptom of something else broken *before* this method call in GTK/SWT. The reason why it was happening here is because of a questionable way how ControlDecoration painting works - it reacts on every paint request of the whole widget tree above the attached widget, producing so a steady _gdk_window_get_origin() calls stream while painting. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. We haven't fixed the problem in SWT, but at least the bug incarnation in the IDE seem to be fixed. Let's declare as fixed, it is better than saying "closed invalid". |
Created attachment 264860 [details] jstack when Eclipse hangs Using Neon.1 (M20160907-1200) on Ubuntu 16.04, GTK 3.18.9, EGit 4.4.0.201606070830-r I right click on my git repository, select "Push branch 'something'...", go to "Advanced push" dialog and click Next, the dialog hangs with current operation showing "Getting remote branches information". Reproducible: always. In jstack only the main thread looks suspicious with the following trace: "main" #1 prio=6 os_prio=0 tid=0x00007f7d3000a000 nid=0x171d runnable [0x00007f7d36bdb000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._gdk_window_get_origin(Native Method) at org.eclipse.swt.internal.gtk.OS.gdk_window_get_origin(OS.java:5940) at org.eclipse.swt.widgets.Control.toDisplay(Control.java:1559) at org.eclipse.jface.fieldassist.ControlDecoration.getDecorationRectangle(ControlDecoration.java:1188) at org.eclipse.jface.fieldassist.ControlDecoration.lambda$1(ControlDecoration.java:623) at org.eclipse.jface.fieldassist.ControlDecoration$$Lambda$99/1490901066.paintControl(Unknown Source) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:231) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) Attaching full jstack. I have the following output in console, probably not related: log4j:WARN No appenders could be found for logger (org.eclipse.jgit.util.FS). log4j:WARN Please initialize the log4j system properly. *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug