Comment 1 Eric Williams 2015-12-18 08:15:53 EST

Hello,

What version of Eclipse are you using, which version of GTK, and what is your OS?

Comment 2 Stephane Epardaud 2015-12-18 08:50:13 EST

Eclipse Mars.1 4.5.1 on Linux (Ubuntu) 

ii  libgtk-3-0:amd64      3.14.13-0ubuntu amd64           GTK+ graphical user interface library
ii  libgtk2.0-0:amd64     2.24.27-0ubuntu amd64           GTK+ graphical user interface library

Comment 3 Eric Williams 2016-01-18 09:14:27 EST

I can't reproduce this bug. I am using the latest nightly (N20160117-2000), on GTK3.18.6.

Comment 4 Stephane Epardaud 2016-01-18 09:22:52 EST

Where can I get this nightly so I can try it too?

Comment 5 Eric Williams 2016-01-18 09:33:28 EST

(In reply to Stephane Epardaud from comment #4)
> Where can I get this nightly so I can try it too?

On this page: http://download.eclipse.org/eclipse/downloads/

Right at the bottom there is a section for nightly builds, clicking on the build ID will take you to a page where you can download the build for your platform/architecture.

Comment 6 Stephane Epardaud 2016-01-18 11:23:10 EST

Overall I think this is much worse:

$ ./eclipse-N20160117-2000/eclipse 
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

Which then exits :(

Comment 7 Eric Williams 2016-01-19 12:33:42 EST

(In reply to Stephane Epardaud from comment #6)
> Overall I think this is much worse:
> 
> $ ./eclipse-N20160117-2000/eclipse 
> Gtk-Message: GtkDialog mapped without a transient parent. This is
> discouraged.
> 
> Which then exits :(

I still can't seem to reproduce this bug. Is this reproducible with a simple Java project or do you have a special workspace configured?

Comment 8 Stephane Epardaud 2016-01-19 14:17:46 EST

Well, I'd very much like to start Neon too, isn't that another bug? Or is it already known?

Comment 9 Daniel Wille 2016-12-15 13:38:07 EST

I ran into what I believe is a variant of this today. Here's my snippet:

java.lang.StackOverflowError
	at org.eclipse.swt.custom.TreeEditor$1.controlResized(TreeEditor.java:100)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:236)
	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:1345)
	at org.eclipse.swt.widgets.TreeColumn.gtk_size_allocate(TreeColumn.java:406)
	at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2011)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5490)
	at org.eclipse.swt.internal.gtk.OS._gtk_widget_size_allocate(Native Method)
	at org.eclipse.swt.internal.gtk.OS.gtk_widget_size_allocate(OS.java:15083)
	at org.eclipse.swt.widgets.Control.forceResize(Control.java:798)
	at org.eclipse.swt.widgets.Tree.getClientAreaInPixels(Tree.java:1165)
	at org.eclipse.swt.widgets.Scrollable.getClientArea(Scrollable.java:227)
	at org.eclipse.swt.custom.TreeEditor.computeBounds(TreeEditor.java:145)
	at org.eclipse.swt.custom.ControlEditor.layout(ControlEditor.java:225)
	at org.eclipse.swt.custom.TreeEditor.layout(TreeEditor.java:327)
	at org.eclipse.swt.custom.TreeEditor$1.controlResized(TreeEditor.java:100)

I'm running CentOS 7 (GTK 3.14), and Neon (4.6.0). In my case I was looking at some details in the properties view. I'm unsure if it was when I clicked on something, or tried to scroll something that triggered the actual event.

Comment 10 Eric Williams 2018-03-20 13:33:24 EDT

Is this still reproducible? There was a fix for StackOverflows on Ubuntu recently (last summer IIRC). Please try with a 4.8 milestone build (preferably M6).

Comment 11 Eric Williams 2018-03-27 11:04:53 EDT

I'm going to close this ticket for now as the issue reported is with Neon. Please reopen this bug if the issue still occurs on a recent 4.8 I-build.

Comment 12 Mark Peters 2020-01-09 17:04:20 EST

Created attachment 281435 [details]
Test case

I am able to consistently repeat the TreeEditor version of this error with the attached test file.

Here is my environment info:

OS: centos-release-7-5.1804.4.el7.centos.x86_64
GTK: 3.22.10-4.el7
Desktop environment: MATE 1.16.2
Eclipse: 4.12.0.I20190605-1800

Comment 13 Andrey Loskutov 2020-01-09 17:07:52 EST

(In reply to Mark Peters from comment #12)
> Created attachment 281435 [details]
> Test case
> 
> I am able to consistently repeat the TreeEditor version of this error with
> the attached test file.

Thanks, reopening. Which GTK theme is used? Can you try Adwaita? Can you also switch to Gnome and try with this desktop?

Comment 14 Andrey Loskutov 2020-01-09 17:08:30 EST

.

Comment 15 Mark Peters 2020-01-09 17:47:58 EST

I think I was on BlueMenta2, but the error occurred with Adwaita as well. I tried on Gnome (3.22.2) and it did NOT occur, and I also tried on Cinammon (2.8.8), and it did occur.

Comment 16 Mark Peters 2020-01-09 18:51:42 EST

Also, my Gnome testing was with Adwaita, in case that was unclear. The problem seems to have to do with the fact that in TreeColumn.gtk_size_allocate, "width" bounces back and forth between two values (1848 and 1834 for me right now), so it repeatedly sends resize events.

Comment 17 Mark Peters 2020-02-12 11:05:36 EST

I am actually able to repeat this on Gnome using the attached test case if I set the GTK_OVERLAY_SCROLLING environment variable to 0. That causes the scroll bars to be permanently shown when they are needed, instead of just being overlaid when you mouse over them, so that variable makes the scroll bars work like MATE.

My environment has updated slightly:
OS: centos-release-7-7.1908.0.el7.centos.x86_64
GTK: 3.22.30
Desktop environment: GNOME 3.28.2
Eclipse: 4.12.0.I20190605-1800

Comment 18 Mark Peters 2020-02-12 11:17:25 EST

Created attachment 281799 [details]
Test case trimmed further

Here is a test case that is trimmed down a bit further.

Comment 19 Mark Peters 2020-02-12 17:59:46 EST

Created attachment 281802 [details]
OverlaidVerticalScrollBarCovered

Comment 20 Mark Peters 2020-02-12 18:02:34 EST

Comment on attachment 281802 [details]
OverlaidVerticalScrollBarCovered

Accidentally added this screenshot to the wrong bug...

Comment 21 Andrey Loskutov 2020-02-20 03:01:46 EST

(In reply to Mark Peters from comment #18)
> Created attachment 281799 [details]
> Test case trimmed further
> 
> Here is a test case that is trimmed down a bit further.

Many thanks! This is really helpful, the problem can be reproduced on 4.15 master.

Mark, could you please sign ECA (https://www.eclipse.org/legal/ECA.php), so that we can commit your snippet as test case?

Also if you are interested to provide a patch, feel free to check https://wiki.eclipse.org/Platform/How_to_Contribute .

Note: we've found exact same problem in the custom product based on 4.12 Eclipse, in two different places with Table / Tree editors. Stack is same, here the one from 4.15 master / attached snippet:

	at org.eclipse.swt.widgets.TreeColumn.gtk_size_allocate(TreeColumn.java:414)
	at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2278)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5928)
	at org.eclipse.swt.internal.gtk.GTK.gtk_widget_size_allocate(Native Method)
	at org.eclipse.swt.widgets.Control.forceResize(Control.java:896)
	at org.eclipse.swt.widgets.Tree.getClientAreaInPixels(Tree.java:1265)
	at org.eclipse.swt.widgets.Scrollable.getClientArea(Scrollable.java:230)
	at org.eclipse.swt.custom.TreeEditor.computeBounds(TreeEditor.java:140)
	at org.eclipse.swt.custom.ControlEditor.layout(ControlEditor.java:218)
	at org.eclipse.swt.custom.TreeEditor.layout(TreeEditor.java:322)
	at org.eclipse.swt.custom.TreeEditor$1.controlResized(TreeEditor.java:103)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:239)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5687)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1423)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1449)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1428)
	at org.eclipse.swt.widgets.TreeColumn.gtk_size_allocate(TreeColumn.java:414)
	at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2278)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:5928)
	at org.eclipse.swt.internal.gtk.GTK.gtk_widget_size_allocate(Native Method)
	at org.eclipse.swt.widgets.Control.forceResize(Control.java:896)
	at org.eclipse.swt.widgets.Tree.getClientAreaInPixels(Tree.java:1265)
	at org.eclipse.swt.widgets.Scrollable.getClientArea(Scrollable.java:230)
	at org.eclipse.swt.custom.TreeEditor.computeBounds(TreeEditor.java:140)
	at org.eclipse.swt.custom.ControlEditor.layout(ControlEditor.java:218)
	at org.eclipse.swt.custom.TreeEditor.layout(TreeEditor.java:322)
	at org.eclipse.swt.custom.TreeEditor$1.controlResized(TreeEditor.java:103)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:239)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5687)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1423)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1449)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1428)
	at org.eclipse.swt.widgets.TreeColumn.gtk_size_allocate(TreeColumn.java:414)

Comment 22 Andrey Loskutov 2020-02-20 03:09:09 EST

One thing that immediately strikes if one goes the stack: org.eclipse.swt.widgets.Tree.getClientAreaInPixels() calls forceResize();

This is unexpected (at least for me) - a "get" method actively triggers resize()??? Removing this fixes the snippet, need to check if that has any side effects.

Comment 23 Andrey Loskutov 2020-02-20 03:51:48 EST

(In reply to Andrey Loskutov from comment #22)
> One thing that immediately strikes if one goes the stack:
> org.eclipse.swt.widgets.Tree.getClientAreaInPixels() calls forceResize();
> 
> This is unexpected (at least for me) - a "get" method actively triggers
> resize()??? Removing this fixes the snippet, need to check if that has any
> side effects.

The pattern seem to be implemented in Composite, Scrollable, Table and Tree. I don't see any obvious regression after some smoke testing in the IDE after removing the forceResize() calls from the classes above, just wondering if that was needed on GTK2 before and "survived" in the code till now.

Comment 24 Eclipse Genie 2020-02-20 03:53:32 EST

New Gerrit change created: https://git.eclipse.org/r/158020

Comment 25 Alexander Kurtakov 2020-02-20 04:04:30 EST

(In reply to Andrey Loskutov from comment #23)
> (In reply to Andrey Loskutov from comment #22)
> > One thing that immediately strikes if one goes the stack:
> > org.eclipse.swt.widgets.Tree.getClientAreaInPixels() calls forceResize();
> > 
> > This is unexpected (at least for me) - a "get" method actively triggers
> > resize()??? Removing this fixes the snippet, need to check if that has any
> > side effects.
> 
> The pattern seem to be implemented in Composite, Scrollable, Table and Tree.
> I don't see any obvious regression after some smoke testing in the IDE after
> removing the forceResize() calls from the classes above, just wondering if
> that was needed on GTK2 before and "survived" in the code till now.

Seeing that it has been there in 2009 (SWT repo misses proper history prior to that) it could even be GTK1 need that survived till now. It's a huge pain uncovering these things and gettind rid of them.

Comment 26 Eclipse Genie 2020-03-02 08:59:58 EST

New Gerrit change created: https://git.eclipse.org/r/158678

Comment 27 Simeon Andreev 2020-03-02 10:07:52 EST

I see a ping-pong between widths 1973 and 1992 in TreeColumn.gtk_size_allocate(long, long). This causes the endless loop and eventual stack overflow.

For the tree, I see a stable allocation in Control.forceResize():

GtkAllocation {0, 0, 1992, 72}

The tree column however fluctuates:

GtkAllocation {0, 0, 1973, 24}
GtkAllocation {0, 0, 1992, 24}

Of course, if I set GTK_OVERLAY_SCROLLING=1 then the snippet runs "fine". So I'm guessing this is bug in GTK3.

Comment 28 Eclipse Genie 2020-03-02 10:09:19 EST

Gerrit change https://git.eclipse.org/r/158678 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=697bfc6d52100863ae803e2baa7d94968cae3b7b

Comment 29 Eclipse Genie 2020-03-14 16:20:38 EDT

Gerrit change https://git.eclipse.org/r/158020 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=42cced92611c0eea6694cb93193ba1af4087018e

Comment 30 Andrey Loskutov 2020-03-14 16:24:59 EDT

I plan to keep it opened till M3. If no one will complain, we can close, otherwise we switch to plan B (like the patch set from Simeon).

Comment 31 Eclipse Genie 2020-03-18 17:12:16 EDT

New Gerrit change created: https://git.eclipse.org/r/159675

Comment 32 Alexander Kurtakov 2020-03-19 09:07:02 EDT

Created attachment 282148 [details]
Image of misrendered dialog

Comment 33 Alexander Kurtakov 2020-03-19 09:08:05 EDT

(In reply to Alexander Kurtakov from comment #32)
> Created attachment 282148 [details]
> Image of misrendered dialog

Andrey,  API baseline edit dialog is broken right now as seen on the picture, resize fixes it. If I launch eclipse with -Dorg.eclipse.swt.resizeOnGetClientArea=true it is back to normal.

Comment 34 Andrey Loskutov 2020-03-19 09:25:16 EDT

(In reply to Alexander Kurtakov from comment #33)
> (In reply to Alexander Kurtakov from comment #32)
> > Created attachment 282148 [details]
> > Image of misrendered dialog
> 
> Andrey,  API baseline edit dialog is broken right now as seen on the
> picture, resize fixes it. If I launch eclipse with
> -Dorg.eclipse.swt.resizeOnGetClientArea=true it is back to normal.

Interesting. I can't reproduce on GTK 3.22.

Can you please attach your swt* values from About->Intallation Details -> Configuration? Is that a Hi DPI screen? Wayland?
Any errors in the log?
How do you start the dialog - I was from Preferences -> Plugin Development -> API Baselines -> Double click on existing one.

Comment 35 Alexander Kurtakov 2020-03-19 09:39:49 EDT

(In reply to Andrey Loskutov from comment #34)
> (In reply to Alexander Kurtakov from comment #33)
> > (In reply to Alexander Kurtakov from comment #32)
> > > Created attachment 282148 [details]
> > > Image of misrendered dialog
> > 
> > Andrey,  API baseline edit dialog is broken right now as seen on the
> > picture, resize fixes it. If I launch eclipse with
> > -Dorg.eclipse.swt.resizeOnGetClientArea=true it is back to normal.
> 
> Interesting. I can't reproduce on GTK 3.22.

3.24.14 here

> 
> Can you please attach your swt* values from About->Intallation Details ->
> Configuration?
org.eclipse.swt.internal.deviceZoom=100
org.eclipse.swt.internal.gtk.theme=Adwaita
org.eclipse.swt.internal.gtk.version=3.24.14


> Is that a Hi DPI screen? 
No.  dimensions:    1920x1080 pixels (508x286 millimeters)


> Wayland?
Yes

> Any errors in the log?
Nothing relevant IMHO

> How do you start the dialog - I was from Preferences -> Plugin Development
> -> API Baselines -> Double click on existing one.
Single click and Edit button for me. I doubt this is the problem though.

Comment 36 Andrey Loskutov 2020-03-19 09:46:13 EDT

(In reply to Alexander Kurtakov from comment #35)
> > Wayland?
> Yes

Can you please try with X11? Just want to sort out if this is GTK version difference or X11 vs Wayland. 

I *believe* we could miss something at creation time of the widgets, so if we don't find the reason, we could modify the code to call the forceResize() only on very fist time (and not over and over again, that leads to the stack overflow).

If you can debug that - could you attach the stack trace from where the first call to getClientAreaInPixels() -> forceRecise() is coming in your environment?

Comment 37 Alexander Kurtakov 2020-03-19 09:57:26 EDT

(In reply to Andrey Loskutov from comment #36)
> (In reply to Alexander Kurtakov from comment #35)
> > > Wayland?
> > Yes
> 
> Can you please try with X11? Just want to sort out if this is GTK version
> difference or X11 vs Wayland. 
> 
> I *believe* we could miss something at creation time of the widgets, so if
> we don't find the reason, we could modify the code to call the forceResize()
> only on very fist time (and not over and over again, that leads to the stack
> overflow).
> 
> If you can debug that - could you attach the stack trace from where the
> first call to getClientAreaInPixels() -> forceRecise() is coming in your
> environment?

Works on X11, broken on Wayland. I can't debug it right now as getting new builds proper on new infra is top priority right now.

Comment 38 Roland Grunberg 2020-03-25 11:08:33 EDT

(In reply to Alexander Kurtakov from comment #33)
> (In reply to Alexander Kurtakov from comment #32)
> > Created attachment 282148 [details]
> > Image of misrendered dialog
> 
> Andrey,  API baseline edit dialog is broken right now as seen on the
> picture, resize fixes it. If I launch eclipse with
> -Dorg.eclipse.swt.resizeOnGetClientArea=true it is back to normal.

Version: 2020-06 (4.16)
Build id: I20200322-1800

I'm seeing the same behaviour but with the JDT Refactor -> Pull Down context menu only on Wayland. I can confirm the issue goes away with usage of the -Dorg.eclipse.swt.resizeOnGetClientArea=true .

Comment 39 Andrey Loskutov 2020-03-25 11:34:33 EDT

(In reply to Roland Grunberg from comment #38)
> Version: 2020-06 (4.16)
> Build id: I20200322-1800
> 
> I'm seeing the same behaviour but with the JDT Refactor -> Pull Down context
> menu only on Wayland.

You mean not the menu size, but the wizard, do you? 

Roland, can yo debug that may be? I have only RHEL7.4 no Wayland here.

> I *believe* we could miss something at creation time of the widgets, so if
> we don't find the reason, we could modify the code to call the forceResize()
> only on very fist time (and not over and over again, that leads to the stack
> overflow).
> 
> If you can debug that - could you attach the stack trace from where the
> first call to getClientAreaInPixels() -> forceResize() is coming in your
> environment?

Comment 40 Roland Grunberg 2020-03-26 11:25:45 EDT

(In reply to Andrey Loskutov from comment #39)
> (In reply to Roland Grunberg from comment #38)
> > Version: 2020-06 (4.16)
> > Build id: I20200322-1800
> > 
> > I'm seeing the same behaviour but with the JDT Refactor -> Pull Down context
> > menu only on Wayland.
> 
> You mean not the menu size, but the wizard, do you? 
> 
> Roland, can yo debug that may be? I have only RHEL7.4 no Wayland here.
> 
> > I *believe* we could miss something at creation time of the widgets, so if
> > we don't find the reason, we could modify the code to call the forceResize()
> > only on very fist time (and not over and over again, that leads to the stack
> > overflow).
> > 
> > If you can debug that - could you attach the stack trace from where the
> > first call to getClientAreaInPixels() -> forceResize() is coming in your
> > environment?

Yes, sorry for the confusion. The issue is with the wizard. I just accessed it through the mouse context menu.

I noticed that you provided instructions for exactly what to look at, so I can definitely do that, assuming I get to it before Alex does.

Comment 41 Roland Grunberg 2020-03-26 16:16:26 EDT

If I just start up a child Eclipse (on Wayland), the first call I see to forceResize() is below.

Thread [main] (Suspended (breakpoint at line 886 in Control))	
	ImageBasedFrame(Control).forceResize() line: 886	
	ImageBasedFrame(Composite).getClientAreaInPixels() line: 756	
	ImageBasedFrame(Scrollable).getClientArea() line: 233	
	ImageBasedFrame(Composite).minimumSize(int, int, boolean) line: 1354	
	ImageBasedFrame(Composite).computeSizeInPixels(int, int, boolean) line: 260	
	ImageBasedFrame(Control).computeSize(int, int, boolean) line: 842	
	ImageBasedFrame(Control).pack(boolean) line: 1628	
	ImageBasedFrame$1.controlResized(ControlEvent) line: 89	
	TypedListener.handleEvent(Event) line: 239	
	EventTable.sendEvent(Event) line: 89	
	Display.sendEvent(EventTable, Event) line: 5685	
	ToolBar(Widget).sendEvent(Event) line: 1423	
	ToolBar(Widget).sendEvent(int, Event, boolean) line: 1449	
	ToolBar(Widget).sendEvent(int) line: 1428	
	ToolBar(Control).setBounds(int, int, int, int, boolean, boolean) line: 1244	
	ToolBar(Composite).setBounds(int, int, int, int, boolean, boolean) line: 1597	
	ToolBar.setBounds(int, int, int, int, boolean, boolean) line: 582	
	ToolBar(Control).setSize(Point) line: 1390	
	ToolBar(Control).pack(boolean) line: 1628	
	ToolBarManager.relayout(ToolBar, int, int) line: 214	
	ToolBarManager.update(boolean) line: 386	
	PluginActionSetBuilder$ActionSetContribution.contributeCoolbarAction(ActionDescriptor, ActionSetActionBars) line: 437	
	PluginActionSetBuilder$ActionSetContribution.contribute(IActionBars, boolean, boolean) line: 346	
	PluginActionSetBuilder.readActionExtensions(PluginActionSet, IWorkbenchWindow) line: 256	
	PluginActionSetBuilder.processActionSets(List<PluginActionSet>, WorkbenchWindow) line: 213	
	ActionPresentation.setActionSets(IActionSetDescriptor[]) line: 190	
	WorkbenchWindow.updateActionSets() line: 2595	
	WorkbenchWindow.setup() line: 930	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 566	
	MethodRequestor.execute() line: 58	
	InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002	
	InjectorImpl.internalInject(Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 139	
	InjectorImpl.inject(Object, PrimaryObjectSupplier) line: 95	
	ContextInjectionFactory.inject(Object, IEclipseContext) line: 83	
	Workbench.createWorkbenchWindow(IAdaptable, IPerspectiveDescriptor, MWindow, boolean) line: 1503	
	Workbench.openWorkbenchWindow(IAdaptable, IPerspectiveDescriptor, MWindow, boolean) line: 2524	
	Workbench.getWorkbenchPage(MPart) line: 1995	
	Workbench.setReference(MPart, IEclipseContext) line: 2040	
	Workbench.lambda$11(Event) line: 1931	
	705825928.handleEvent(Event) line: not available	
	UIEventHandler.lambda$0(Event) line: 38	
	1892646174.run() line: not available	
	UISynchronizer(Synchronizer).syncExec(Runnable) line: 236	
	UISynchronizer.syncExec(Runnable) line: 133	
	Display.syncExec(Runnable) line: 5795	
	E4Application$1.syncExec(Runnable) line: 219	
	UIEventHandler.handleEvent(Event) line: 38	
	EventHandlerWrapper.handleEvent(Event, Permission) line: 205	
	EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 203	
	EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1	
	EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 234	
	ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 151	
	EventAdminImpl.dispatchEvent(Event, boolean) line: 132	
	EventAdminImpl.sendEvent(Event) line: 75	
	EventComponent.sendEvent(Event) line: 44	
	EventBroker.send(String, Object) line: 55	
	UIEventPublisher.notifyChanged(Notification) line: 63	
	PartImpl(BasicNotifierImpl).eNotify(Notification) line: 424	
	PartImpl.setContext(IEclipseContext) line: 469	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 637	
	PartRenderingEngine$1.run() line: 547	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement, Object, IEclipseContext) line: 531	
	ElementReferenceRenderer.createWidget(MUIElement, Object) line: 73	
	PartRenderingEngine.createWidget(MUIElement, Object) line: 1002	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 662	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	StackRenderer.showTab(MUIElement) line: 1297	
	StackRenderer(LazyStackRenderer).postProcess(MUIElement) line: 105	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 680	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	SashRenderer(SWTPartRenderer).processContents(MElementContainer<MUIElement>) line: 71	
	SashRenderer.processContents(MElementContainer<MUIElement>) line: 148	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 676	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	PerspectiveRenderer(SWTPartRenderer).processContents(MElementContainer<MUIElement>) line: 71	
	PerspectiveRenderer.processContents(MElementContainer<MUIElement>) line: 51	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 676	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	PerspectiveStackRenderer.showTab(MUIElement) line: 82	
	PerspectiveStackRenderer(LazyStackRenderer).postProcess(MUIElement) line: 105	
	PerspectiveStackRenderer.postProcess(MUIElement) line: 64	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 680	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	SashRenderer(SWTPartRenderer).processContents(MElementContainer<MUIElement>) line: 71	
	SashRenderer.processContents(MElementContainer<MUIElement>) line: 148	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 676	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	WBWRenderer(SWTPartRenderer).processContents(MElementContainer<MUIElement>) line: 71	
	WBWRenderer.processContents(MElementContainer<MUIElement>) line: 666	
	PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 676	
	PartRenderingEngine.safeCreateGui(MUIElement) line: 768	
	PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739	
	PartRenderingEngine$2.run() line: 733	
	SafeRunner.run(ISafeRunnable) line: 45	
	PartRenderingEngine.createGui(MUIElement) line: 717	
	PartRenderingEngine$5.run() line: 1086	
	Realm.runWithDefault(Realm, Runnable) line: 338	
	PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1049	
	E4Workbench.createAndRunUI(MApplicationElement) line: 155	
	Workbench.lambda$3(Display, WorkbenchAdvisor, int[]) line: 658	
	892262157.run() line: not available	
	Realm.runWithDefault(Realm, Runnable) line: 338	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 557	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 154	
	IDEApplication.start(IApplicationContext) line: 150	
	EclipseAppHandle.run(Object) line: 203	
	EclipseAppLauncher.runApplication(Object) line: 137	
	EclipseAppLauncher.start(Object) line: 107	
	EclipseStarter.run(Object) line: 401	
	EclipseStarter.run(String[], Runnable) line: 255	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 566	
	Main.invokeFramework(String[], URL[]) line: 657	
	Main.basicRun(String[]) line: 594	
	Main.run(String[]) line: 1447	
	Main.main(String[]) line: 1420

Comment 42 Eric Williams 2020-03-31 08:53:03 EDT

Removing the force resize in Composite is probably not the best approach, as it can affect all kinds of corner cases which aren't immediately visible. Ask me how I know. :)

A lot of these resize calls are needed because GTK caches everything and sometimes you won't get an accurate size if you don't "kick" GTK first. I remember working on the blank wizard/dialog page issue ~5 years ago and it was related to this. It's best to revert the disabling of forceResize() and pursue a better fix.

IMO this bug (the overflow, not the wizard/dialog page being blank) looks similar to another stack overflow we had in Tree/Table awhile ago, where doing something in some case triggered an overflow due to callback/event loop running infinitely. 

A a good place to start: look into why it happens on GTK_OVERLAY_SCROLLING=0 only. My guess is that the scrollbars add ~5px of size somewhere, triggering a "size mismatch" in SWT, and causes an endless loop be sent. Maybe some bad size checking logic somewhere? Looking in Table.gtk_size_allocate() there is some of this logic to check whether or not to send the SWT.Resize event. This could probably be tweaked somehow.

It might also be worth looking into removing forceResize() just from Table/Tree's getClientArea() methods. This way you get a more surgical fix without potentially breaking all kinds of Composites.

Comment 43 Eclipse Genie 2020-04-05 15:32:24 EDT

New Gerrit change created: https://git.eclipse.org/r/160496

Comment 44 Eclipse Genie 2020-04-05 16:23:41 EDT

Gerrit change https://git.eclipse.org/r/160496 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ff04b1368cdd788c5cf9614656d1c6723b502c5f

Comment 45 Andrey Loskutov 2020-04-05 16:26:32 EDT

(In reply to Eclipse Genie from comment #43)
> New Gerrit change created: https://git.eclipse.org/r/160496

Just a temporary workaround for Wayland users to keep old behavior. 

Eric, many thanks for pointers, I've just have no time now to follow up, lot of internal work. I keep thinking on this bug, and will try to follow your proposals.

Comment 46 Alexander Kurtakov 2020-05-12 15:27:56 EDT

Is there anything planned for 4.16 here? If not please either close and open new one for further work or retarget.

Comment 47 Andrey Loskutov 2020-05-14 17:22:16 EDT

Opened bug 563191 for Wayland. On X11 we haven't seen regression so far, so marking as resolved.