Community
Participate
Working Groups
Eclipse 4.3M4 run with SWT_GTK3=1 Fedora 17, Gtk+ 3.4.4 1. Open Problems view (empty) 2. Click on Description header for sorting 3. Eclipse hangs, using 100% CPU Stack trace: "main" prio=10 tid=0x00007fc8f4008800 nid=0xc79 runnable [0x00007fc8fb1e0000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk.OS._gdk_cairo_region_create_from_surface(Native Method) at org.eclipse.swt.internal.gtk.OS.gdk_cairo_region_create_from_surface(OS.java:4965) at org.eclipse.swt.graphics.Region.gdk_region_polygon(Region.java:120) at org.eclipse.swt.graphics.Region.add(Region.java:164) at org.eclipse.swt.custom.CTabFolderRenderer.drawBackground(CTabFolderRenderer.java:595) at org.eclipse.swt.custom.CTabFolderRenderer.drawSelected(CTabFolderRenderer.java:1343) at org.eclipse.swt.custom.CTabFolderRenderer.draw(CTabFolderRenderer.java:547) at org.eclipse.swt.custom.CTabFolder.onPaint(CTabFolder.java:1960) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:284) 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.Control.gtk_draw(Control.java:3087) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2084) at org.eclipse.swt.widgets.Control.windowProc(Control.java:5334) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4532) 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:8549) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1241) 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:2281) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3324) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:275) at org.eclipse.ui.internal.progress.ProgressManager$3.run(ProgressManager.java:960) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:995) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:970) at org.eclipse.ui.internal.progress.WorkbenchSiteProgressService.busyCursorWhile(WorkbenchSiteProgressService.java:186) at org.eclipse.ui.internal.views.markers.CachedMarkerBuilder.refreshContents(CachedMarkerBuilder.java:259) at org.eclipse.ui.internal.views.markers.ExtendedMarkersView.setPrimarySortField(ExtendedMarkersView.java:1403) at org.eclipse.ui.internal.views.markers.ExtendedMarkersView.access$2(ExtendedMarkersView.java:1398) at org.eclipse.ui.internal.views.markers.ExtendedMarkersView$7.widgetSelected(ExtendedMarkersView.java:826) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248) 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.Display.runDeferredEvents(Display.java:3705) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3326) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1049) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:939) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:79) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:587) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:542) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) 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:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1443) at org.eclipse.equinox.launcher.Main.main(Main.java:1419) When taking the stack trace multiple times during the hang, org.eclipse.swt.custom.CTabFolderRenderer.draw is always part of it. The drawSelected and lines above that vary.
I hit this bug too while using the latest 4.3 I-build I20130108-0800 on Ubuntu 12.04 (64-bit). The GTK+ version being used is 3.4.2. I dumped 4 stack traces during the hang and they are quite similar to the one above except that instead of org.eclipse.swt.custom.CTabFolderRenderer.draw, I see org.eclipse.e4.ui.workbench.renderers.swt.CTabRendering.draw which further invokes different native calls in each of the stack traces. Attaching a sample snippet of the trace below... 3XMTHREADINFO "main" J9VMThread:0x00007F4C7409EE00, j9thread_t:0x00007F4C7402DB40, java/lang/Thread:0x00007F4C50F46108, state:CW, prio=6 3XMTHREADINFO1 (native thread ID:0x1A38, native priority:0x6, native policy:UNKNOWN) 3XMTHREADINFO2 (native stack address range from:0x00007F4C78239000, to:0x00007F4C78A3A000, size:0x801000) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at org/eclipse/swt/internal/gtk/OS._gdk_cairo_region_create_from_surface(Native Method) 4XESTACKTRACE at org/eclipse/swt/internal/gtk/OS.gdk_cairo_region_create_from_surface(OS.java:4965(Compiled Code)) 4XESTACKTRACE at org/eclipse/swt/graphics/Region.gdk_region_polygon(Region.java:120(Compiled Code)) 4XESTACKTRACE at org/eclipse/swt/graphics/GC.convertRgn(GC.java:457(Compiled Code)) 4XESTACKTRACE at org/eclipse/swt/graphics/GC.getClipping(GC.java:2486(Compiled Code)) 4XESTACKTRACE at org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.drawTabHeader(CTabRendering.java:225) 4XESTACKTRACE at org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.draw(CTabRendering.java:177(Compiled Code)) 4XESTACKTRACE at org/eclipse/swt/custom/CTabFolder.onPaint(CTabFolder.java:1940) 4XESTACKTRACE at org/eclipse/swt/custom/CTabFolder$1.handleEvent(CTabFolder.java:284)
This is a not a hang. There is a CTabFolder that is continuously getting paint events. I was able to reproduce this on Fedora 18.
I have not figured out what is causing this infinite painting loop, but it is possible to stop it by double clicking on a view stack header to maximize it.
Snippet that reproduces it. Problem happens because CTabFolder calls computeSize() on the topRight control from inside the paint listener which causes another redraw event to be queue. import org.eclipse.swt.SWT; import org.eclipse.swt.custom.CTabFolder; import org.eclipse.swt.custom.CTabItem; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.*; public class Test { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); CTabFolder folder = new CTabFolder(shell, SWT.NONE); CTabItem item = new CTabItem(folder, SWT.NONE); item.setText("Item"); Composite c = new Composite(folder, SWT.NONE); final ToolBar bar = new ToolBar(c, SWT.NONE); ToolItem titem = new ToolItem(bar, SWT.PUSH); titem.setText("Item"); folder.setTopRight(c); c.setLayout(new FillLayout()); shell.setLayout(new FillLayout()); folder.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("paint="); } }); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
In GTK3, we have our own SWTFixed widget which allows us to stop using gtk_widget_set_size_request() in order to set the size of a widget. This means that Control.computeNativeSize() does not have to reset the size request to (-1,-1) so that it can get the preferred size of a widget anymore. This resetting is what was causing the infinite paint loop. Fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d453cf5437fbe11ecd8d5bdf8ed46b521a6689e4
