Community
Participate
Working Groups
See bug 569468 comment 28: A sequence of 'new Display()' ... 'display.dispose()' ... 'new Display()' throws a warning: Gdk-CRITICAL **: 19:53:51.919: gdk_threads_set_lock_functions: assertion 'gdk_threads_lock == NULL && gdk_threads_unlock == NULL' failed I understand that 'swt_set_lock_functions()' simply needs to remember if it already set the functions?
This problem causes a lot of noise in GTK JUnit :(
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/182683
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/182683 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=72d6bd1adf59dee6bae147a0a504c91855c51bd1
we now have test fails in xtext-eclipse with this change and the latest lightly you can find jstacks in the ticket https://github.com/eclipse/xtext-eclipse/issues/1698
(In reply to Christian Dietrich from comment #4) > we now have test fails in xtext-eclipse > with this change and the latest lightly > > you can find jstacks in the ticket > https://github.com/eclipse/xtext-eclipse/issues/1698 The UI thread hangs here: "main" #1 prio=6 os_prio=0 cpu=1519,39ms elapsed=212,17s tid=0x00007f4f1c016800 nid=0x30f8 runnable [0x00007f4f21338000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.gtk3.GTK3.gtk_events_pending(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4590) at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:772) at org.eclipse.ui.internal.Workbench$20.runWithException(Workbench.java:1653) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:36) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:236) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:133) at org.eclipse.swt.widgets.Display.syncExec(Display.java:6011) at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:94) at org.eclipse.ui.internal.Workbench.init(Workbench.java:1645) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2759) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:637) at org.eclipse.ui.internal.Workbench$$Lambda$132/0x00000008403d1c40.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152) at org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:29) at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:122) at org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:35) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@11.0.11/Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:654) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1462) at org.eclipse.equinox.launcher.Main.main(Main.java:1435)
steps to reproduce git clone https://github.com/eclipse/xtext-eclipse.git cd xtext-eclipse mvn clean install -Platest (needs java 11)
going back to http://download.eclipse.org/eclipse/updates/4.21-I-builds/I20210630-1800/ seems to solve the issue
Hang is not acceptable. I'll revert the original patch
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/182522
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/182522 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=12ef90f1fe2467b669f110e5a218da396ce8a1d8
(In reply to Christian Dietrich from comment #6) > steps to reproduce > > git clone https://github.com/eclipse/xtext-eclipse.git > cd xtext-eclipse > mvn clean install -Platest > > (needs java 11) Can reproduce on same system where same SDK build works fine as IDE. The question is: what is special for the test case? Here is what jinfo says for the hanging instance: VM Arguments: jvm_args: -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86_64 -Xmx2G -Dosgi.clean=true java_command: /home/aloskuto/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.6.200.v20210416-2027/org.eclipse.equinox.launcher-1.6.200.v20210416-2027.jar -data /tmp/xtext/xtext-eclipse/org.eclipse.xtext.ui.tests/target/work/data -install /tmp/xtext/xtext-eclipse/org.eclipse.xtext.ui.tests/target/work -configuration /tmp/xtext/xtext-eclipse/org.eclipse.xtext.ui.tests/target/work/configuration -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties /tmp/xtext/xtext-eclipse/org.eclipse.xtext.ui.tests/target/surefire.properties -pluginCustomization /tmp/xtext/xtext-eclipse/org.eclipse.xtext.ui.tests/../releng/org.eclipse.xtext.tycho.tests.parent/pluginCustomization.ini Both surefire.properties and pluginCustomization.ini looks innocent. So it is surefire itself / test code that somehow initializes the Display in a way that it hangs. org.eclipse.tycho.surefire.osgibooter.UITestApplication / org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication?
I suspect that 'gdk_threads_enter()' is now called on some unexpected thread.
the interesting points is that many of the testcases before in the same reactore are perfectly fine. but i am not sure if this is due different dependency lists or just bad luck. but the hang in xtext.ui.tests seems to be consistent.
will check if the bundle start level in the tests pom play a role
https://github.com/eclipse/xtext-eclipse/compare/cd_justAtestForX seems to have helped thus the question is: what does the autostart or startlevel of that bundle trigger to cause the problem
Moving out of M1
I don't know when I'll be able to look into it or if at all.
