Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[tromey]

Synopsis: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Sep 11 12:41:40 2002
Responsible-Changed-Why:
    I'm handling the administrivia
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Wed Sep 11 12:41:40 2002
State-Changed-Why:
    Thanks for your report.
    Andrew recently checked in a fix which allows this
    bytecode but issues a warning.
    This will appear in gcc 3.3.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5794

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Tom Tromey]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Adam Dingle <adam@medovina.org>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK  1.4 compiler
Date: 02 Mar 2002 18:41:05 -0700

 >>>>> "Adam" == Adam Dingle <adam@medovina.org> writes:
 
 Adam> I'll be curious to see what you think.  I do seem to get this
 Adam> kind of unusual exception table entry almost any time I compile
 Adam> a try...finally block with JDK 1.4.
 
 Ok, I looked at this class file.
 The exception range is 0-5, with the handler at 5.
 One important thing to know is that the upper limit of the exception
 handler is the address of the instruction *just after* the handled
 region.
 
 I haven't looked at the gcj failure yet.
 
 Tom

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Adam Dingle]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Adam Dingle <adam@medovina.org>
To: tromey@redhat.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK
 1.4 compiler
Date: Sat, 02 Mar 2002 10:40:55 -0800

 One more observation: GCJ can't verify the byte code which it itself 
 generates for the method.
 
 [adam@localhost foo]$ gcj3 --version
 3.0.2
 [adam@localhost foo]$ gcj3 -C Foo.java
 [adam@localhost foo]$ gcj3 Foo.class
 Foo.java: In class `Foo':
 Foo.java: In method `Foo.invoke()':
 Foo.java:6: verification error at PC=11
 Foo.java:6: stack overflow
 [adam@localhost foo]$
 
 -adam

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Tom Tromey]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: adam@medovina.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
Date: 02 Mar 2002 11:56:48 -0700

 >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
 
 Tom> Suppose the VM encounters an internal error and throws an
 Tom> exception after it has set the PC to the start of the exception
 Tom> handler but before the first instruction of the handler (probably
 Tom> a pop or an astore) is executed.  This leads inexorably to a
 Tom> stack overflow.
 
 I thought about this more and my idea here is just wrong.
 When an exception is throw the stack is cleared before the exception
 is pushed.  So this scenario can't happen.
 
 I'll look into this a bit more soon.
 
 Tom

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Adam Dingle]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Adam Dingle <adam@medovina.org>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK
 1.4 compiler
Date: Sat, 02 Mar 2002 09:20:27 -0800

 --Boundary_(ID_SqrWNdAHJp+UIEkskG5ToA)
 Content-type: text/plain; charset=iso-8859-1
 Content-transfer-encoding: 7BIT
 
 Another note.  I tried compiling the same source file with Sun's JDK 1.3
 compiler.  It compiled the method differently, and did not generate any
 exception table entry with a target address inside the range of addresses
 which the entry itself protects.  Nevertheless, GCJ 3.0.2 still fails to
 verify the class; it reports
 
 Foo.java: In class `Foo':
 Foo.java: In method `Foo.invoke()':
 Foo.java:6: verification error at PC=11
 Foo.java:6: stack overflow
 
 The method's disassembly looks like this:
 
 Method int invoke()
    0 iconst_1
    1 istore_1
    2 jsr 13
    5 iload_1
    6 ireturn
    7 astore_2
    8 jsr 13
   11 aload_2
   12 athrow
   13 astore_3
   14 iconst_3
   15 ireturn
 Exception table:
    from   to  target type
      0     7     7   any
 
 I've included the .class file generated by the JDK 1.3 compiler as an
 attachment to this message.  (I found another test case where the compiler
 generates code which causes GCJ to seg fault, but I'll file a separate bug
 report for that one.)
 
 adam
 
 -------------------------------------------------------
 
 
 
 --Boundary_(ID_SqrWNdAHJp+UIEkskG5ToA)
 Content-type: application/java; charset=iso-8859-1; name=Foo.class
 Content-transfer-encoding: base64
 Content-disposition: attachment; filename=Foo.class
 
 yv66vgADAC0ADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJU
 YWJsZQEABmludm9rZQEAAygpSQEAClNvdXJjZUZpbGUBAAhGb28uamF2YQwABAAFAQADRm9vAQAQ
 amF2YS9sYW5nL09iamVjdAAhAAIAAwAAAAAAAgABAAQABQABAAYAAAAdAAEAAQAAAAUqtwABsQAA
 AAEABwAAAAYAAQAAAAEAAQAIAAkAAQAGAAAANAABAAQAAAAQBDyoAAsbrE2oAAUsv04FrAABAAAA
 BwAHAAAAAQAHAAAACgACAAAABgAHAAgAAQAKAAAAAgAL
 
 --Boundary_(ID_SqrWNdAHJp+UIEkskG5ToA)--

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Adam Dingle]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Adam Dingle <adam@medovina.org>
To: tromey@redhat.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK
 1.4 compiler
Date: Fri, 01 Mar 2002 00:01:18 -0800

 --Boundary_(ID_qN3wNA75EjmM1jjnp01ldQ)
 Content-type: text/plain; charset=iso-8859-1
 Content-transfer-encoding: 7BIT
 
 Tom,
 
 > Could you upload the resulting .class file?
 > Just reply to this email and attach it, keeping gcc-gnats on the CC
 > line.
 
 No problem - I've attached the .class file to this reply.
 
 > Adam> When Sun's Java compiler in JDK 1.4 compiles a try...finally
 > Adam> block, it emits a (useless and unused) exception table entry
 > Adam> whose target is within the range of protected instructions.
 > Adam> There is nothing inherently unsafe with this, but we check for
 > Adam> this case and reject it in verify.c.
 >
 > It seems to me that this must be invalid.
 
 Well, I'm not sure.  Section 4.9.5 of the Java Virtual Machine Specification 
 does include the following text: "Java virtual machine code produced by 
 Sun's compiler for the Java programming language always generates exception 
 handlers such that ... The handler for an exception will never be inside the 
 code that is being protected ... These restrictions are not enforced by the 
 class file verifier since they do not pose a threat to the integrity of the 
 Java virtual machine." (see 
 http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html)
 
 > Adam> I tried that and then gcj complained about a stack overflow in
 > Adam> the same .class file.
 >
 > Yeah.  Suppose the VM encounters an internal error and throws an
 > exception after it has set the PC to the start of the exception
 > handler but before the first instruction of the handler (probably a
 > pop or an astore) is executed.  This leads inexorably to a stack
 > overflow.  I imagine the gij verifier will die on this too.
 
 That is a scary thought, although it's hard for me to imagine any sort of 
 error that might happen just at that moment.
 
 > I'd like to see the class file though.  It's possible there are
 > obscure extenuating circumstances.  Or perhaps they've tightened the
 > verification spec and I don't yet know about it.
 
 I'll be curious to see what you think.  I do seem to get this kind of unusual 
 exception table entry almost any time I compile a try...finally block with 
 JDK 1.4.
 
 -adam
 
 --Boundary_(ID_qN3wNA75EjmM1jjnp01ldQ)
 Content-type: application/java; name=Foo.class
 Content-transfer-encoding: base64
 Content-disposition: attachment; filename=Foo.class
 
 yv66vgAAAC4ADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJU
 YWJsZQEABmludm9rZQEAAygpSQEAClNvdXJjZUZpbGUBAAhGb28uamF2YQwABAAFAQADRm9vAQAQ
 amF2YS9sYW5nL09iamVjdAAhAAIAAwAAAAAAAgABAAQABQABAAYAAAAdAAEAAQAAAAUqtwABsQAA
 AAEABwAAAAYAAQAAAAEAAQAIAAkAAQAGAAAAPAABAAQAAAAQBDyoAAsbrE2oAAUsv04FrAACAAAA
 BQAHAAAABwALAAcAAAABAAcAAAAKAAIAAAAGAAcACAABAAoAAAACAAs=
 
 --Boundary_(ID_qN3wNA75EjmM1jjnp01ldQ)--

Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Tom Tromey]

The following reply was made to PR java/5794; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: adam@medovina.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
Date: 28 Feb 2002 17:47:43 -0700

 >>>>> "Adam" == adam  <adam@medovina.org> writes:
 
 Adam> Number:         5794
 Adam> Synopsis:       gcj fails to verify .class file generated by Sun JDK 1.4 compiler
 
 Could you upload the resulting .class file?
 Just reply to this email and attach it, keeping gcc-gnats on the CC
 line.
 
 Adam> When Sun's Java compiler in JDK 1.4 compiles a try...finally
 Adam> block, it emits a (useless and unused) exception table entry
 Adam> whose target is within the range of protected instructions.
 Adam> There is nothing inherently unsafe with this, but we check for
 Adam> this case and reject it in verify.c.
 
 It seems to me that this must be invalid.
 
 Adam> I tried that and then gcj complained about a stack overflow in
 Adam> the same .class file.
 
 Yeah.  Suppose the VM encounters an internal error and throws an
 exception after it has set the PC to the start of the exception
 handler but before the first instruction of the handler (probably a
 pop or an astore) is executed.  This leads inexorably to a stack
 overflow.  I imagine the gij verifier will die on this too.
 
 I'd like to see the class file though.  It's possible there are
 obscure extenuating circumstances.  Or perhaps they've tightened the
 verification spec and I don't yet know about it.
 
 Tom

java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[adam]

>Number:         5794
>Category:       java
>Synopsis:       gcj fails to verify .class file generated by Sun JDK 1.4 compiler
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 28 12:15:59 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Adam Dingle
>Release:        gcc version 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3)
>Organization:
>Environment:
Red Hat Linux 7.2 on a Pentium PC
>Description:
If I use Sun's Java compiler (from JDK 1.4) to compile a .java file containing a try...finally block, then try to use gcj to compile the .class file into executable code, gcj complains with the error message "bad pc in exception_table".

Here's what's going on.  Recall that a Java .class file contains an exception table for each method.  Each entry in the exception table contains a range (from, to) of instructions to protect as well as a target instruction to jump to if an exception occurs within that range.  When Sun's Java compiler in JDK 1.4 compiles a try...finally block, it emits a (useless and unused) exception table entry whose target is within the range of protected instructions.  There is nothing inherently unsafe with this, but we check for this case and reject it in verify.c.

Unfortunately, the fix is apparently not as simple as removing the line which makes this check (the line "|| (handler_pc >= start_pc && handler_pc < end_pc)" in verify_jvm_instructions() in verify.c); I tried that and then gcj complained about a stack overflow in the same .class file.  I don't have time to look at the verification code more right now, so I'm filing a bug report in case someone else wants to pick up where I left off.
>How-To-Repeat:
$ /usr/java/j2sdk1.4.0/bin/javac Foo.java
$ gcj Foo.class
Foo.java: In class `Foo':
Foo.java: In method `Foo.invoke()':
Foo.java:6: bad pc in exception_table
$ 
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-java; name="Foo.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Foo.java"

cHVibGljIGNsYXNzIEZvbwp7CglwdWJsaWMgaW50IGludm9rZSgpCgl7CgkJdHJ5IHsKCQkJcmV0
dXJuIDE7CgkJfSAgZmluYWxseSB7CgkJCXJldHVybiAyOwoJCX0KCX0KfQo=