This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: java/4766: Stack overflow when compiling .class file
- From: Tom Tromey <tromey at redhat dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 19 Nov 2001 19:46:01 -0000
- Subject: Re: java/4766: Stack overflow when compiling .class file
- Reply-to: Tom Tromey <tromey at redhat dot com>
[Get raw message]
The following reply was made to PR java/4766; it has been noted by GNATS.
From: Tom Tromey <tromey@redhat.com>
To: blanen@uinetworks.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/4766: Stack overflow when compiling .class file
Date: 19 Nov 2001 13:04:43 -0700
>>>>> "Blane" == blanen <blanen@uinetworks.com> writes:
Blane> If you put a return statement in a finally statement it will
Blane> cause a stack overflow.
I looked at this a little bit.
`gcj -C' generates this bytecode for your method:
0: getstatic #15=<Field java.lang.System.out java.io.PrintStream>
3: ldc #17=<String "x">
5: invokevirtual #23=<Method java.io.PrintStream.println (java.lang.String)void>
8: goto 16
11: astore_1
12: aload_1
13: invokevirtual #29=<Method java.lang.Throwable.printStackTrace ()void>
16: jsr 28
19: goto 35
22: astore_2
23: jsr 28
26: aload_2
27: athrow
28: astore_1
29: iconst_0
30: istore_3
31: iload_3
32: ireturn
33: ret 1
This code won't verify. Instruction 19 is a `goto' to an instruction
which doesn't exist.
Also, since the `finally' clause doesn't return, we probably shouldn't
be generating the jsr/ret pairs here. In the code above the `ret 1'
is dead, but `gcj --syntax-only' doesn't seem to notice.
FWIW javac generates this bytecode:
0: getstatic #10=<Field java.lang.System.out java.io.PrintStream>
3: ldc #1=<String "x">
5: invokevirtual #12=<Method java.io.PrintStream.println (java.lang.String)void>
8: goto 20
11: astore_1
12: aload_1
13: invokevirtual #11=<Method java.lang.Throwable.printStackTrace ()void>
16: goto 20
19: pop
20: iconst_0
21: ireturn
This seems much better.
So I think this report shows not only a verifier bug (plus which: the
gcj verifier doesn't seem to notice that the goto is out of bounds --
I didn't see any code in gcj to detect this situation), but also a few
bytecode generation problems.
Unfortunately I don't have time to fix this. A workaround is to
either use javac to compile bytecode in such cases, or just always
compile from .java->.o. The latter is preferable anyway.
Tom