Community
Participate
Working Groups
In recent builds, the test summary page for GTK2 ([1] for example) shows the results only for tests under AllBrowserTests and ignores AllNonBrowserTests even though console logs ([2] for example) indicate that all the tests actually ran successfully. The GTK3 test results page does not have this issue. [1] http://download.eclipse.org/eclipse/downloads/drops4/N20160927-2000/testresults/html/org.eclipse.swt.tests_ep47N-unit-lin64_linux.gtk.x86_64_8.0.html [2] http://download.eclipse.org/eclipse/downloads/drops4/N20160927-2000/testresults/ep47N-unit-lin64_linux.gtk.x86_64_8.0/org.eclipse.swt.tests.junit.AllNonBrowserTests.txt
Apparently, Windows test result summary also has the same problem, Mac and GTK3 reports are getting generated properly.
(In reply to Arun Thondapu from comment #1) > Apparently, Windows test result summary also has the same problem, Mac and > GTK3 reports are getting generated properly. Just checked that N20161002-2000 shows this problem for Windows test results but N20161001-1500 doesn't...
Windows tests look OK now, but GTK2 tests are still timing out regularly, e.g. from http://download.eclipse.org/eclipse/downloads/drops4/N20161016-2000/testresults/consolelogs/ep47N-unit-lin64_linux.gtk.x86_64_8.0_consolelog.txt : java-test: [echo] Running org.eclipse.swt.tests.junit.AllNonBrowserTests. Result file: /opt/public/hipp/homes/genie.platform/workspace/ep47N-unit-lin64/workarea/N20161016-2000/eclipse-testing/results/ep47N-unit-lin64_linux.gtk.x86_64_8.0/org.eclipse.swt.tests.junit.AllNonBrowserTests.xml [echo] timout property: 7200000 [echo] frameworkvmargs: -Xms256m -Xmx1024m -Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -Dhttp.nonProxyHosts="172.30.206.*" -Dhttps.nonProxyHosts="172.30.206.*" -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -Dftp.nonProxyHosts="172.30.206.*" -Djava.io.tmpdir=/opt/public/hipp/homes/genie.platform/workspace/ep47N-unit-lin64/tmp [echo] vmargs: [echo] extraVMargs: [echo] frameworkperfargs: [echo] crash loglocationarg (if any): ${loglocationarg} [echo] crash loglocation (if not default): [java] INFO: timeoutScreenOutputDir: /opt/public/hipp/homes/genie.platform/workspace/ep47N-unit-lin64/workarea/N20161016-2000/eclipse-testing/results/ep47N-unit-lin64_linux.gtk.x86_64_8.0/timeoutScreens [java] INFO: timeout: 7200000 [java] starting EclipseTestRunnerTimer with timeout=7080000 at 2016-10-16 21:31:13 -0400 [java] Timeout: killed the sub-process [java] Java Result: -1 Added logging of test start times via http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e0ebbdf73a7f169aead702612bcf9f8edfa101be
(In reply to Markus Keller from comment #3) > Added logging of test start times via > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=e0ebbdf73a7f169aead702612bcf9f8edfa101be The latest N-build has the logging info [1] and the tests are apparently stuck in Test_org_eclipse_swt_custom_StyledText#test_printLorg_eclipse_swt_printing_Printer(), seems to be running fine locally with both GTK3 and GTK2. [1] http://download.eclipse.org/eclipse/downloads/drops4/N20161017-2000/testresults/ep47N-unit-lin64_linux.gtk.x86_64_8.0/org.eclipse.swt.tests.junit.AllNonBrowserTests.txt
I can reproduce a hang on Ubuntu 14.04 by stopping CUPS: $ sudo service cups stop After that, calls to gtk_enumerate_printers(..., true) block the UI thread forever. This happens on GTK2 and GTK3 for me. Could be https://bugzilla.gnome.org/show_bug.cgi?id=686838 . Thread [main] (Suspended) OS._gtk_enumerate_printers(long, long, long, boolean) line: not available [native method] OS.gtk_enumerate_printers(long, long, long, boolean) line: 10290 Printer.getDefaultPrinterData() line: 143 Test_org_eclipse_swt_custom_StyledText.test_printLorg_eclipse_swt_printing_Printer() line: 2272 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: 498 FrameworkMethod$1.runReflectiveCall() line: 50 FrameworkMethod$1(ReflectiveCallable).run() line: 12 FrameworkMethod.invokeExplosively(Object, Object...) line: 47 InvokeMethod.evaluate() line: 17 RunBefores.evaluate() line: 26 RunAfters.evaluate() line: 27 TestWatcher$1.evaluate() line: 55 RunRules.evaluate() line: 20 BlockJUnit4ClassRunner(ParentRunner<T>).runLeaf(Statement, Description, RunNotifier) line: 325 BlockJUnit4ClassRunner.runChild(FrameworkMethod, RunNotifier) line: 78 BlockJUnit4ClassRunner.runChild(Object, RunNotifier) line: 57 ParentRunner$3.run() line: 290 ParentRunner$1.schedule(Runnable) line: 71 BlockJUnit4ClassRunner(ParentRunner<T>).runChildren(RunNotifier) line: 288 ParentRunner<T>.access$000(ParentRunner, RunNotifier) line: 58 ParentRunner$2.evaluate() line: 268 BlockJUnit4ClassRunner(ParentRunner<T>).run(RunNotifier) line: 363 JUnit4TestReference.run(TestExecution) line: 86 TestExecution.run(ITestReference[]) line: 38 RemoteTestRunner.runTests(String[], String, TestExecution) line: 459 RemoteTestRunner.runTests(TestExecution) line: 678 RemoteTestRunner.run() line: 382 RemoteTestRunner.main(String[]) line: 192 That doesn't explain why it only happens on GTK3 on the same https://hudson.eclipse.org/platform/label/centos/ that runs both lin64 and cen64 tests.
I've enhanced the TracingSuite to confirm the real problem. For atomic tests that run longer than 10 minutes, it now tries to take a stack trace and a screenshot, and then it tries to stop the "main" thread with an IllegalStateException. Also generalized the class and prepared it for a move to org.eclipse.test.performance. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=43c8caf41a0f4ee155bb2f229b244e646b09837f
(In reply to Markus Keller from comment #5) > That doesn't explain why it only happens on GTK3 on the same > https://hudson.eclipse.org/platform/label/centos/ that runs both lin64 and > cen64 tests. Did you mean it happens only on GTK2? The GTK3 tests are looking good on the same centos hudson node. The GTK2 tests for the M-build which are still running on the previous test machine don't have this problem as the GTK2 version there is 2.18.9. I'm wondering why the CUPS service would be disabled on the centos machine... Sravan, can we try to enable it and check if the tests complete running successfully?
(In reply to Arun Thondapu from comment #7) > (In reply to Markus Keller from comment #5) > > That doesn't explain why it only happens on GTK3 on the same > > https://hudson.eclipse.org/platform/label/centos/ that runs both lin64 and > > cen64 tests. > > Did you mean it happens only on GTK2? The GTK3 tests are looking good on the > same centos hudson node. > > The GTK2 tests for the M-build which are still running on the previous test > machine don't have this problem as the GTK2 version there is 2.18.9. > > I'm wondering why the CUPS service would be disabled on the centos > machine... Sravan, can we try to enable it and check if the tests complete > running successfully? If the CUPS service is disabled GTK3 tests also would fail. Since these are not failing there must be some other problem here
http://download.eclipse.org/eclipse/downloads/drops4/N20161019-1250/testresults/ep47N-unit-lin64_linux.gtk.x86_64_8.0/org.eclipse.swt.tests.junit.AllNonBrowserTests.txt confirms that the bug is in gtk_enumerate_printers: org.eclipse.swt.tests.junit.TracingSuite$ThreadDump: for thread "main" at org.eclipse.swt.internal.gtk.OS._gtk_enumerate_printers(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_enumerate_printers(OS.java:10290) at org.eclipse.swt.printing.Printer.getDefaultPrinterData(Printer.java:143) at org.eclipse.swt.tests.junit.Test_org_eclipse_swt_custom_StyledText.test_printLorg_eclipse_swt_printing_Printer(Test_org_eclipse_swt_custom_StyledText.java:2272) org.eclipse.swt.internal.gtk.version=2.24.28 The problem on Hudson is not necessarily that CUPS is not running -- that were just my steps to reproduce locally. Could also be that just no printers are defined. https://bugzilla.gnome.org/show_bug.cgi?id=686838 tells that it's a use-after-free problem, so it's well possible that we're just lucky on GTK3 that memory allocation works a bit different. Bug 215234 is the SWT bug that tracks the blocking gtk_enumerate_printers(). To unblock SWT tests, we can set -Dorg.eclipse.swt.internal.gtk.disablePrinting until the GTK bug gets fixed or we find a workaround in SWT (via bug 215234).
(In reply to Markus Keller from comment #9) > To unblock SWT tests, we can set > -Dorg.eclipse.swt.internal.gtk.disablePrinting until the GTK bug gets fixed > or we find a workaround in SWT (via bug 215234). Done with http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cf8cd8c8978fea9dbf38e8bdcf7968cfcb994d64
(In reply to Markus Keller from comment #10) > (In reply to Markus Keller from comment #9) > > To unblock SWT tests, we can set > > -Dorg.eclipse.swt.internal.gtk.disablePrinting until the GTK bug gets fixed > > or we find a workaround in SWT (via bug 215234). > > Done with > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=cf8cd8c8978fea9dbf38e8bdcf7968cfcb994d64 Thanks Markus! The GTK2 test results in N20161020-2100 are now looking good - http://download.eclipse.org/eclipse/downloads/drops4/N20161020-2100/testresults/html/org.eclipse.swt.tests_ep47N-unit-lin64_linux.gtk.x86_64_8.0.html
Backported to R4_6_maintenance: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8fa8b46bc8e72dbbbf21c07aa6c3353a013d28ed
