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.
JDK 8 JDK 9
8u112Fixed 9Fixed
Related Reports
Relates :  
JDK-8162386 - Revert build.gradle changes added by JDK-8161724
Description
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
java.io.EOFException
        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
4)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1158)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:632)
        at java.lang.Thread.run(Thread.java:804)
Comments
As part of this fix, build.gradle changes are committed by mistake. This build.gradle change is reverted as part of JDK-8162386.
22-07-2016
Changeset: d068aefec850 Author: mbilla Date: 2016-07-22 15:17 +0530 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/d068aefec850
22-07-2016
lgtm
22-07-2016
Testing looks good. +1
20-07-2016
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.
20-07-2016
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.
19-07-2016