Re: java/4766: Stack overflow when compiling .class file

[Tom Tromey <tromey@redhat.com>]

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