JDK-8161724 : EOFException in GZIPInputStream.readUByte while browsing
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-07-19
  • Updated: 2016-07-24
  • Resolved: 2016-07-22
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.
8u112Fixed 9Fixed
Related Reports
Relates :  
While browsing in windows 7 64 bit with jdk-9 in non-jigsaw mode is causing the below exception:

1. Launch HelloWebview and load www.google.com
2. Search any keyword
3. Follow the links.
4. Below Exception is observed.

Jul 20, 2016 12:31:11 AM com.sun.webkit.network.URLLoader doRun
WARNING: Unexpected error
        at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:268)
        at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:259)
        at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:164)
        at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
        at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:91)
        at com.sun.webkit.network.URLLoader.receiveResponse(URLLoader.java:522)
        at com.sun.webkit.network.URLLoader.doRun(URLLoader.java:164)
        at com.sun.webkit.network.URLLoader.lambda$run$0(URLLoader.java:129)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.webkit.network.URLLoader.run(URLLoader.java:128)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:51
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
        at java.lang.Thread.run(Thread.java:804)

As part of this fix, build.gradle changes are committed by mistake. This build.gradle change is reverted as part of JDK-8162386.

Changeset: d068aefec850 Author: mbilla Date: 2016-07-22 15:17 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/d068aefec850


Testing looks good. +1

I can reproduce this consistently with the following URL: http://www.nytimes.com/pages/technology/index.html The proposed fix looks reasonable; I will test it shortly.

webrev: http://cr.openjdk.java.net/~mbilla/8161724/webrev.00/ This fix is subsequent patch on top of JDK-8093859 and JDK-8152393. When GZIPInputStream throws EOFException, Caller of receiveResponse() -> doRun() is actually handling most of the exceptions (including Throwable) and printing "Unexpected error" in case of java.io.EOFException. In receiveResponse() method in URLLoader: When c.getInputStream() throws IOException, currently we are catching the exception and code flow proceeds. In this case, inputStream will be still null. We need to check inputStream for null before we try to create GZIPInputStream. If we pass null, then GZIPInputStream will throw IllegalArgumentException/NullPointerException. If readHeader fails, then GZIPInputStream will throw EOFException/ IOException In fact, the need to check inputStream for null is a side effect of JDK-8093859 fix.