From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-11552-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26495 invoked by alias); 19 Nov 2001 19:46:02 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 26473 invoked by uid 71); 19 Nov 2001 19:46:01 -0000
Date: Tue, 13 Nov 2001 19:13:00 -0000
Message-ID: <20011119194601.26470.qmail@sourceware.cygnus.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Tom Tromey <tromey@redhat.com>
Subject: Re: java/4766: Stack overflow when compiling .class file
Reply-To: Tom Tromey <tromey@redhat.com>
X-SW-Source: 2001-11/txt/msg00304.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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