JDK-8094088 : [Mac] WebView unit tests hang on headless test machines
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-05-04
  • Updated: 2017-01-18
  • Resolved: 2015-05-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9Fixed
Related Reports
Relates :  
JDK-8096769 - [Mac] Swing interop unit tests hangs on headless test machines
Relates :  
JDK-8087682 - Web unit test testDOMWindowAndStyleAccess gets NPE in Utils.getScreen
Relates :  
JDK-8172988 - gradle :web:test should run in headless mode
Description
Our WebView unit tests are hanging on Mac when run on our Hudson test slaves, which run in headless mode. Any test that cannot run headless must be qualified by "FULL_TEST=true".

To reproduce this:

1. remotely ssh into a Mac that is not logged into the console and has no monitor or keyboard attached to it
2. Run "gradle :web:test"
3. The test suite will hang when running the first test that starts the FX runtime

The reason for the hang is that the QuantumRenderer thread gets an exception during screen initialization in headless mode, and that exception isn't propagated to the test harness.

Here is the exception that leads to the hang:

javafx.scene.web.BindingTest STANDARD_ERROR
    RenderJob.run: internal exception
    java.lang.ArrayIndexOutOfBoundsException: 0
    	at java.util.Arrays$ArrayList.get(Arrays.java:3835)
    	at java.util.Collections$UnmodifiableList.get(Collections.java:1369)
    	at com.sun.glass.ui.Screen.getMainScreen(Screen.java:61)
    	at com.sun.prism.sw.SWPipeline.getDefaultResourceFactory(SWPipeline.java:82)
    	at com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipeline.java:120)
    	at com.sun.javafx.tk.quantum.QuantumRenderer.lambda$createResourceFactory$411(QuantumRenderer.java:161)
    	at com.sun.javafx.tk.quantum.QuantumRenderer$$Lambda$42/1907614384.run(Unknown Source)
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    	at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    	at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
    	at java.lang.Thread.run(Thread.java:744)
Comments
9 changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/54272d8ed0a2 8u60 changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/80b25b9f942d
12-05-2015
I filed RT-40764 as a follow-on JIRA to track the (non-fatal) NPE we now get in one of the web unit tests as a result of running headless.
12-05-2015
Thanks, Kevin!
06-05-2015
I agree that #3 is the best long term solution. I also added it as a short term workaround to our Hudson jobs and they all passed overnight.
05-05-2015
My personal vote is for the 3rd solution. Most of the functionality we test is essentially headless (like JS bridge, load listeners etc.). Also, there might be a standalone WebEngine instance not connected with WebView. We should be able to use (and test) it that way.
05-05-2015
Running the smoke tests with "-PHEADLESS_TEST=true" (which enables Monocle headless mode) seems to workaround the problem. We need a more robust long-term solution. Possible solutions include: 1) Only running the javafx.scene.web.* tests when FULL_TEST=true (skipping them for smoke tests). This is the easiest approach. The only downside is that these tests will run less often (daily rather than continuously), and developers won't run them by default. 2) Fix the AIOOBE in screen.getMainScreen (this is fragile since something else could change that breaks the default toolkit from running headless, and also could mask problems, so I don't favor this one) 3) Decide that headless is a reasonable solution for web tests, and change the build script to use it. There is at least one test that is still getting an exception (but doesn't seem to fail), so this would require some work. There may be other solutions, but those are the obvious ones.
04-05-2015