User account creation filtered due to spam.

Bug 5537 - Error compiling simple bytecode with jsr
Summary: Error compiling simple bytecode with jsr
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.0.3
: P2 normal
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2002-01-30 04:26 UTC by daniel.bonniot
Modified: 2005-03-09 09:04 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-01-10 11:33:53


Attachments
A.class (221 bytes, application/octet-stream)
2003-05-21 15:17 UTC, daniel.bonniot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description daniel.bonniot 2002-01-30 04:26:01 UTC
This case involves calling return in a try/finally block,
and compiling from bytecode.

public class A 
{
  public static void main(String[] args)
  {
    try{
      return;
    }
    finally{
    }
  }
}

gcj compiles correctly from source, but fails on the corresponding
bytecode (attached):
$ gcj A.class
A.java: In class `A':
A.java: In method `A.main(java.lang.String[])':
A.java:6: verification error at PC=8
A.java:6: loading local variable 1 which has unknown type

$ javap -c A.class
Compiled from A.java
public class A extends java.lang.Object {
    public A();
    public static void main(java.lang.String[]);
}

Method A()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return

Method void main(java.lang.String[])
   0 jsr 10
   3 return
   4 astore_1
   5 jsr 10
   8 aload_1
   9 athrow
  10 astore_2
  11 ret 2
Exception table:
   from   to  target type
     0     4     4   any

Release:
3.0.3

Environment:
Debian package gcj-3.0
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.3

How-To-Repeat:
gcj A.class
Comment 1 Tom Tromey 2002-01-30 16:54:16 UTC
From: Tom Tromey <tromey@redhat.com>
To: Daniel.Bonniot@inria.fr
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: 30 Jan 2002 16:54:16 -0700

 >>>>> "Daniel" == Daniel Bonniot <Daniel.Bonniot@inria.fr> writes:
 
 Daniel> This case involves calling return in a try/finally block,
 Daniel> and compiling from bytecode.
 
 I've looked at this.  gcj still rejects the bytecode in this PR.  I
 think it does so incorrectly; the bytecode looks fine to me and both
 `java' and `gij' pass it.
 
 How did you generate the bytecode?  If you did so with gcj, note that
 gcj 3.1 no longer generates the same bytecode.  Now the method is
 simply `return'.  (This doesn't affect the fact that this is a gcj
 bug.)
 
 Tom

Comment 2 daniel.bonniot 2002-01-31 10:56:09 UTC
From: Daniel Bonniot <Daniel.Bonniot@inria.fr>
To: tromey@redhat.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Thu, 31 Jan 2002 10:56:09 +0100

 Tom Tromey wrote:
 
 > 
 > I've looked at this.  gcj still rejects the bytecode in this PR.  I
 > think it does so incorrectly; the bytecode looks fine to me and both
 > `java' and `gij' pass it.
 > 
 > How did you generate the bytecode?  
 
 
 The bytecode is the output of Sun/Blackdown javac 1.3.1 on the given A.java
 The error was first found with my own compiler (http://nice.sf.net) that 
 generates java bytecode and now optionally calls gcj on the ouput.
 
 > If you did so with gcj, note that
 > gcj 3.1 no longer generates the same bytecode.  Now the method is
 > simply `return'.  
 
 
 I suppose this is only an optim due to the fact that the finally block 
 is empty. I tried to find the smallest case that triggers the problem.
 
 I have gcj 3.0.3 and it works fine on the source. I haven't tried to 
 make it produce bytecode.
 
  > This doesn't affect the fact that this is a gcj bug.
 
 Right.
 

Comment 3 daniel.bonniot 2002-10-08 09:32:33 UTC
From: Daniel Bonniot <Daniel.Bonniot@inria.fr>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Tue, 8 Oct 2002 09:32:33 +0200

 I could reproduce this bug with 
 gcj-3.2 (GCC) 3.2.1 20020912 (Debian prerelease)

Comment 4 Dara Hazeghi 2003-05-12 12:08:59 UTC
From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, java-prs@gcc.gnu.org
Cc:  
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Mon, 12 May 2003 12:08:59 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=5537
 
 Hello,
 
 I can confirm that this bug is still present in gcc 3.2, 3.3 branch and  
 mainline (20030511) on i686-linux.
 
 Dara
Comment 5 Andrew Pinski 2003-05-24 17:19:37 UTC
confiirmed on mainline (20030524).
GCJ produces bytecode that only returns:
Method void main(java.lang.String[])
   0 return

On the other hand javac (SUN JDK 1.4) produces:
Method void main(java.lang.String[])
   0 jsr 10
   3 return
   4 astore_1
   5 jsr 10
   8 aload_1
   9 athrow
  10 astore_2
  11 ret 2
Comment 6 Andrew Pinski 2003-11-19 06:45:39 UTC
The message has changed on the mainline (20031018):
[zhivago2:~/src/gccPRs] pinskia% ~/fsf-clean-nocheck/bin/gcj A.class
A.java: In class `A':
A.java: In method `A.main(java.lang.String[])':
A.java:8: warning: exception handler inside code that is being protected
A.java:10: error: stack underflow
A.java:10: warning: unreachable bytecode from 4 to before 10
Comment 7 Ranjit Mathew 2004-07-15 06:05:37 UTC
The problem is that for the instruction following a jsr,
we need to merge the type state just before the jsr with
the modified type state from the ret of the subroutine
that the jsr calls - we were not keeping track of the type
state before the jsr at all, leading to this bug.

I have a very simple patch that fixes this bug, but it
unfortunately reveals other problems in the verifier,
some of which cause libjava testsuite failures. I'll
submit a full patch if I'm able to resolve these.

Here is the simple patch that cures the bug exposed by
this PR as against the current mainline:

Index: verify.c
===================================================================
--- verify.c    2004-07-15 11:19:53.000000000 +0530
+++ verify.c    2004-07-15 11:21:41.000000000 +0530
@@ -1346,6 +1346,10 @@ verify_jvm_instructions (JCF* jcf, const
          {
            tree target = lookup_label (oldpc + IMMEDIATE_s2);
            tree return_label = lookup_label (PC);
+           if (LABEL_TYPE_STATE (return_label) == NULL_TREE)
+             {
+               merge_type_state (return_label);
+             }
            PUSH_TYPE (return_address_type_node);
            /* The return label chain will be null if this is the first
               time we've seen this jsr target.  */
Comment 8 Andrew Pinski 2004-10-14 14:16:30 UTC
New error message on the mainline:
A.java: In class `A':
A.java: In method `A.main(java.lang.String[])':
A.java:8: error: stack underflow
Comment 9 Andrew Haley 2004-10-21 13:40:10 UTC
We're merging the new verifier on the gcj-abi-2-dev-branch.

Once that is done, this bug should be fixed.
Comment 10 Ranjit Mathew 2005-01-10 11:26:33 UTC
Now that the BC-ABI work has been merged, the testcase no longer
gives an error when compiled with "-findirect-dispatch".

However, it ICEs when compiled without!

Relevant info:

Program received signal SIGSEGV, Segmentation fault.
verify_jvm_instructions (jcf=0xb75f5500, byte_ops=0x87adcb4 "¨", length=13)
    at /home/ranmath/src/gcc/gcc-20050110/gcc/java/verify.c:712
712             if (TREE_CODE (tmp) != TREE_LIST)
(gdb) bt
#0  verify_jvm_instructions (jcf=0xb75f5500, byte_ops=0x87adcb4 "¨", length=13)
    at /home/ranmath/src/gcc/gcc-20050110/gcc/java/verify.c:712
#1  0x0807de9d in expand_byte_code (jcf=0xb75f5500, method=0x87a85f8)
    at /home/ranmath/src/gcc/gcc-20050110/gcc/java/expr.c:2960
#2  0x0808c774 in parse_class_file ()
    at /home/ranmath/src/gcc/gcc-20050110/gcc/java/jcf-parse.c:919
#3  0x0808ec8a in java_parse_file (set_yydebug=0)
    at /home/ranmath/src/gcc/gcc-20050110/gcc/java/jcf-parse.c:1284
#4  0x082e03a0 in toplev_main (argc=142247416, argv=0xbffface4)
    at /home/ranmath/src/gcc/gcc-20050110/gcc/toplev.c:996
#5  0x0038579d in __libc_start_main () from /lib/tls/libc.so.6
#6  0x08049b71 in _start ()

Comment 11 Andrew Haley 2005-01-10 11:33:53 UTC
It's extremely unlikely that anyone will fix bugs in the old verifier.

However, it is still used for the non- indirect dispatch case.  I don't know if
it's possible to use the new verifier for that: probably not.  It certainly
could be done.
Comment 12 Ranjit Mathew 2005-01-10 11:59:25 UTC
In that case, we should either make -findirect-dispatch the default
or try to fix this bug. Users will otherwise unnecessarily be bitten
by such old verifier bugs. I'm willing to try hunting this particular
bug down if -findirect-dispatch can't be made the default just yet.
Comment 13 Daniel Bonniot 2005-03-02 00:11:19 UTC
What's the take on this bug? Can indirect-dispatch be made the default in the
foreseable future? Can the old verifier be fixed?

I'm now running nightly builds of gcj on the Nice compiler testsuite (1250
testcases). There are currently 11 failures, and 4 seem to be instances of this
verifier bug. So fixing this would be a great improvement.
Comment 14 Ranjit Mathew 2005-03-02 07:54:35 UTC
(In reply to comment #13)
> What's the take on this bug? Can indirect-dispatch be made the default in the
> foreseable future? Can the old verifier be fixed?
> 
> I'm now running nightly builds of gcj on the Nice compiler testsuite (1250
> testcases). There are currently 11 failures, and 4 seem to be instances of this
> verifier bug. So fixing this would be a great improvement.

See:

  http://gcc.gnu.org/ml/java-patches/2005-q1/msg00568.html

which makes even the non-indirect-dispatch case use the new
shiny verifier.

It definitely fixes this PR and a whole lot of other verifier
bugs. Can you test it with your application too? (Thanks in
advance for doing it.)
Comment 15 daniel.bonniot 2005-03-02 10:13:27 UTC
Subject: Re:  Error compiling simple bytecode with jsr


>  http://gcc.gnu.org/ml/java-patches/2005-q1/msg00568.html
>
>which makes even the non-indirect-dispatch case use the new
>shiny verifier.
>
>It definitely fixes this PR and a whole lot of other verifier
>bugs. Can you test it with your application too? (Thanks in
>advance for doing it.)
>  
>

OK, I patched my tree, I'll report the results (fixes and regressions) 
after the next build.

In your list message, you mention only one fix in the gcc testsuite, 
pr13107. Does this mean pr5537 is not fixed, or it does not have a testcase?

Comment 16 Ranjit Mathew 2005-03-02 13:09:46 UTC
> OK, I patched my tree, I'll report the results (fixes and regressions) 
> after the next build.

Thanks.


> In your list message, you mention only one fix in the gcc testsuite, 
> pr13107. Does this mean pr5537 is not fixed, or it does not have a testcase?

The latter. We do not have any bytecode verification tests
in the libjava testsuite (yet). We use the Mauve verifier testsuite instead.
Comment 17 daniel.bonniot 2005-03-02 13:42:55 UTC
Subject: Re:  Error compiling simple bytecode with jsr

I just finished running my testsuite with gcj/new_verifier. The results are 
very good:

6 fixes (only 5 failures instead of 11 previously)
0 regressions
overhead is small (around 1% of user time)

I say: go for it!

Great work of whoever worked on this new verifier.
Comment 18 Ranjit Mathew 2005-03-09 09:04:09 UTC
Now that the new verifier has been enabled, this bug has been fixed.