public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-03-02 17:16 Tom Tromey
0 siblings, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2002-03-02 17:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-09-11 12:41 tromey
0 siblings, 0 replies; 8+ messages in thread
From: tromey @ 2002-09-11 12:41 UTC (permalink / raw)
To: adam, gcc-bugs, gcc-prs, java-prs, nobody, 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-03-02 10:46 Adam Dingle
0 siblings, 0 replies; 8+ messages in thread
From: Adam Dingle @ 2002-03-02 10:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-03-02 10:36 Tom Tromey
0 siblings, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2002-03-02 10:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-03-02 9:26 Adam Dingle
0 siblings, 0 replies; 8+ messages in thread
From: Adam Dingle @ 2002-03-02 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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)--
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-03-01 0:06 Adam Dingle
0 siblings, 0 replies; 8+ messages in thread
From: Adam Dingle @ 2002-03-01 0:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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)--
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-02-28 22:56 Tom Tromey
0 siblings, 0 replies; 8+ messages in thread
From: Tom Tromey @ 2002-02-28 22:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler
@ 2002-02-28 12:56 adam
0 siblings, 0 replies; 8+ messages in thread
From: adam @ 2002-02-28 12:56 UTC (permalink / raw)
To: gcc-gnats
>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=
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-09-11 19:41 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-02 17:16 java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2002-09-11 12:41 tromey
2002-03-02 10:46 Adam Dingle
2002-03-02 10:36 Tom Tromey
2002-03-02 9:26 Adam Dingle
2002-03-01 0:06 Adam Dingle
2002-02-28 22:56 Tom Tromey
2002-02-28 12:56 adam
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).