Bug 174708 - Unexpected java.io.EOFException
Unexpected java.io.EOFException
Product: Fedora
Classification: Fedora
Component: jessie (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Depends On:
  Show dependency treegraph
Reported: 2005-12-01 11:30 EST by Andrew Overholt
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-23 13:33:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Overholt 2005-12-01 11:30:20 EST
Description of problem:
Consider this test case:

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.MalformedURLException;
import java.net.URL;

public class HttpsTest {

  public static void main(String[] args) {
    String url = "https://bugzilla.redhat.com/bugzilla";
    try {
      BufferedReader read = new BufferedReader(
          new InputStreamReader(new URL(url).openStream()));
    } catch (MalformedURLException e) {
    } catch (IOException e) {


[overholt@tophat tmp]$ javac HttpsTest.java

With the Sun JVM, there is no output and the program exits normally:

[overholt@tophat tmp]$ ~/tmp/jdk1.5.0_03/bin/java HttpsTest
[overholt@tophat tmp]$

However, with gij (using jessie), I get:

[overholt@tophat tmp]$ java HttpsTest
java.io.EOFException: unexpected end of input stream
   at org.metastatic.jessie.provider.ContentType.read(java.io.InputStream)
(Unknown Source)
   at org.metastatic.jessie.provider.RecordInput.readRecord() (Unknown Source)
   at org.metastatic.jessie.provider.RecordInput.pollClose() (Unknown Source)
   at org.metastatic.jessie.provider.SSLSocket.close() (Unknown Source)
   at gnu.java.net.protocol.http.HTTPConnection.closeConnection()
java.io.InputStream, boolean) (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.Request.dispatch() (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.HTTPURLConnection.connect()
   at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream()
   at java.net.URL.openStream() (/usr/lib/libgcj.so.6.0.0)
   at HttpsTest.main(java.lang.String[]) (Unknown Source)
   at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See above.
Actual results:
Stack trace.

Expected results:
No stack trace.

Additional info:
This is preventing use of RH Bugzilla by the Eclipse Bugzilla plugin.
Comment 1 Tom Tromey 2006-01-17 16:56:57 EST
I suspect this is fixed in gcj 4.1.

The old Request.readResponseBody was renamed to
createResponseBodyStream and reworked a bit.
It doesn't appear to close the underlying stream directly any more.

I'm not set up to test this currently though :-(
Comment 2 Thomas Fitzsimmons 2006-01-17 17:01:17 EST
I tested this on my combined GNU Classpath HEAD/GCJ HEAD + GNU Crypto/Jessie
merge tree and I get this:

$ java HttpsTest
javax.net.ssl.SSLProtocolException: java.lang.Object cannot be cast to
   at gnu.javax.net.ssl.provider.Certificate.read (Certificate.java:123)
   at gnu.javax.net.ssl.provider.Handshake.read (Handshake.java:216)
   at gnu.javax.net.ssl.provider.Handshake.read (Handshake.java:110)
   at gnu.javax.net.ssl.provider.SSLSocket.doClientHandshake (SSLSocket.java:1519)
   at gnu.javax.net.ssl.provider.SSLSocket.startHandshake (SSLSocket.java:524)
   at gnu.java.net.protocol.http.HTTPConnection.getSocket (HTTPConnection.java:515)
   at gnu.java.net.protocol.http.HTTPConnection.getOutputStream
   at gnu.java.net.protocol.http.Request.dispatch (Request.java:313)
   at gnu.java.net.protocol.http.HTTPURLConnection.connect
   at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream
   at java.net.URL.openStream (URL.java:683)
   at HttpsTest.main (HttpsTest.java:13)
Caused by: java.security.cert.CertificateException: java.lang.Object cannot be
cast to gnu.java.security.OID
   at gnu.java.security.x509.X509Certificate.<init> (X509Certificate.java:176)
   at gnu.java.security.provider.X509CertificateFactory.generateCert
   at java.security.cert.CertificateFactory.generateCertificate
   at gnu.javax.net.ssl.provider.Certificate.read (Certificate.java:115)
   ...11 more
Caused by: java.lang.ClassCastException: java.lang.Object cannot be cast to
   at gnu.java.security.x509.X509Certificate.parse (X509Certificate.java:714)
   at gnu.java.security.x509.X509Certificate.<init> (X509Certificate.java:166)
   ...15 more
Comment 3 Tom Tromey 2006-01-20 18:42:01 EST
I also see the exception from comment #2.

To see this with a gcc install tree, I add:
to $prefix/lib/security/classpath.security

Then, I run gij like so:
gij -Djava.endorsed.dirs=/usr/share/java/gcj-endorsed/ HttpsTest

This assumes that you have the jessie RPM installed (so that the
jessie jar is in the endorsed directory).

I believe this bug was introduced here:


I haven't looked into running the jessie test case mentioned in that

When I add a workaround for the above, I'm back to the unexpected EOF.

Comment 4 Tom Tromey 2006-01-20 19:40:50 EST
Oops, never mind ... I was re-testing the wrong gij.
With my patch against 4.1, I can get this to work again.
So, I think this is fixed in svn.

Jakub, I've CCd you since this patch should go in the gcj RPM...
Comment 5 Jakub Jelinek 2006-01-23 02:36:54 EST
It made into gcc-4.1.0-0.16 in rawhide.
Comment 6 Andrew Overholt 2006-01-23 11:25:35 EST
Sweet, thanks.  It works for me now.

Note You need to log in before you can comment on or make changes to this bug.