Bug 180418 - ICE while compiling jar or class file (azureus)
ICE while compiling jar or class file (azureus)
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2006-02-07 19:51 EST by Anthony Green
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 4.1.0-0.27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-20 13:29:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Tarball with test code. (4.24 MB, application/octet-stream)
2006-02-07 19:54 EST, Anthony Green
no flags Details
. (1.20 KB, patch)
2006-02-08 10:14 EST, Andrew Haley
no flags Details | Diff

  None (edit)
Description Anthony Green 2006-02-07 19:51:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I'm getting the following ICE from gcj...

org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java: In class 'org.gudy.azureus2.core3.peer.impl.PEPieceImpl':
org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java: In constructor '(org.gudy.azureus2.core3.peer.PEPeerManager,org.gudy.azureus2.core3.disk.DiskManagerPiece,int)':
org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.

I'm about to upload a tarball for the test code.  Untar it and reproduce with...

gcj -c -g -fPIC -findirect-dispatch -fjni -c org/gudy/azureus2/core3/peer/impl/PEPieceImpl.class

Removing -findirect-dispatch makes the problem go away.

This is on x86-64.  I haven't tried x86 or other platforms.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. gcj -c -g -fPIC -findirect-dispatch -fjni -c org/gudy/azureus2/core3/peer/impl/PEPieceImpl.class

Additional info:
Comment 1 Anthony Green 2006-02-07 19:54:15 EST
Created attachment 124346 [details]
Tarball with test code.
Comment 2 Jakub Jelinek 2006-02-08 08:02:06 EST
This is a segfault in dwarf2out.c:

    at ../../gcc/dwarf2out.c:11416
(gdb) l
11411   {
11412     gen_type_die (type, context_die);
11414     /* If we're trying to avoid duplicate debug info, we may not have
11415        emitted the member decl for this function.  Emit it now.  */
11417         && ! lookup_decl_die (member))
11418       {
11419         dw_die_ref type_die;
11420         gcc_assert (!decl_ultimate_origin (member));
(gdb) p debug_tree (type)
 <record_type 0x2a98dec790 boolean[]
    type <boolean_type 0x2a98d940b0 boolean asm_written public unsigned QI
        size <integer_cst 0x2a98d7b630 constant invariant 8>
        unit size <integer_cst 0x2a98d7b660 constant invariant 1>
        align 8 symtab -1729758400 alias set -1 precision 1 min <integer_cst
0x2a98d92210 0> max <integer_cst 0x2a98d92240 1>
        pointer_to_this <pointer_type 0x2a98dec9a0> chain <type_decl 0x2a98d8b820
    asm_written type_1 BLK
    size <integer_cst 0x2a98d7bdb0 type <integer_type 0x2a98d870b0 bit_size_type>
constant invariant 128>
    unit size <integer_cst 0x2a98d7bde0 type <integer_type 0x2a98d87000> constant
invariant 16>
    align 64 symtab -1729759040 alias set -1
    fields <field_decl 0x2a98d9e6c0 D.413
        type <record_type 0x2a98d974d0 java.lang.Object tree_3 type_2 type_4 DI
            size <integer_cst 0x2a98d7ba50 constant invariant 64>
            unit size <integer_cst 0x2a98df6e40 constant invariant 8>
            align 64 symtab -1729770688 alias set -1 fields <field_decl
0x2a98d96840 vtable>
            pointer_to_this <pointer_type 0x2a98d97580> chain <type_decl
0x2a98d8bdd0 java.lang.Object>>
        ignored DI file org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java line 0
size <integer_cst 0x2a98d7ba50 64>
        unit size <integer_cst 0x2a98d7ba80 constant invariant 8>
        align 64 offset_align 128
        offset <integer_cst 0x2a98d7b570 constant invariant 0>
        bit offset <integer_cst 0x2a98d7bd50 constant invariant 0>
        chain <field_decl 0x2a98d9e540 length type <integer_type 0x2a98d872c0
            readonly decl_1 decl_3 SI file
org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java line 0
            size <integer_cst 0x2a98d7b900 constant invariant 32>
            unit size <integer_cst 0x2a98d7b540 constant invariant 4>
            align 32 offset_align 128 offset <integer_cst 0x2a98d7b570 0> bit
offset <integer_cst 0x2a98d7ba50 64> context <record_type 0x2a98dec790 boolean[]>
chain <field_decl 0x2a98d9e600 data>>>
    pointer_to_this <pointer_type 0x2a98dec840>>
$4 = void
(gdb) p type->common.chain
$5 = 0x0

I believe it is frontend's responsibility to create TYPE_STUB_DECLs.
Comment 3 Andrew Haley 2006-02-08 09:26:21 EST
This is to do with Java 1.5 versus Java 1.4.  gcj does not yet support Java 1.5.

public class poo
  Object bar (boolean[] bb)
    return bb.clone();

ecj generates:

  1: invokevirtual <Method java.lang.Object.clone ()java.lang.Object>

BEA generates (with -source 1.5):

  1: invokevirtual <Method [Z.clone ()java.lang.Object>

and with -source 1.4:

  1: invokevirtual <Method java.lang.Object.clone ()java.lang.Object>

I'm sure gcj will die with other Java 1.5isms too.
Comment 4 Andrew Haley 2006-02-08 10:04:25 EST
Incidentally, if I fix this in the compiler so that we emit a reference to
boolean[].clone(), the runtime simply fails, as you'd perhaps expect:

Exception in thread "main" java.lang.NoClassDefFoundError: poo
   at java.lang.Class.initializeClass (libgcj.so.7)
   at poo.main (poo.java:10)
Caused by: java.lang.ClassNotFoundException: boolean[] not found in
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

So the runtime would have to be fixed for this to work in the way that is intended.
Comment 5 Andrew Haley 2006-02-08 10:14:28 EST
Created attachment 124384 [details]
Comment 6 Anthony Green 2006-02-08 10:59:18 EST
(In reply to comment #3)
> This is to do with Java 1.5 versus Java 1.4.  gcj does not yet support Java 1.5.

Perhaps this is a bug in the Eclipse compiler then.  Compiling with -target 1.4
emits the sequence you're saying should only be for 1.5.   The azureus ant file
uses -target 1.4.  Compiling with -target 1.3 emits what you're saying is
acceptable for 1.4.  I'm patch the azureus spec file for now.  If you're sure
about this, I'll file a bug upstream with Eclipse. 

(It's been a long time since I've seen an ICE in gcj!  Thanks for your quick
help Andrew)

Comment 9 Tom Tromey 2006-02-08 11:27:54 EST
Offhand I can't think of a reason that calling [Z.clone()
would be invalid for a 1.4 runtime.

I wrote a little test case and the ecj on my FC4 box
generates a call to the array's clone() instead of Object.clone():

public class clone
  public static Object x(String[] z)
    return z.clone();

  public static void main(String[] args)

opsy. jcf-dump -c -v clone|grep invokevirtual
  1: invokevirtual #17=<Method [Ljava.lang.String;.clone ()java.lang.Object>

One (temporary) fix might be to have gcj turns calls to array clone
methods to calls to Object.clone.  (Though the exceptions differ...)
Comment 10 Andrew Haley 2006-02-08 11:50:36 EST
Oops.  When ecj uses defaults, it generates

  <Method java.lang.Object.clone ()java.lang.Object>

with -target 1.4 it generates

  <Method [Z.clone ()java.lang.Object>

I suppose ecj must be generating 1.3 by default.

It's a one-line fix to make gcj generate Object.clone:

Index: expr.c
--- expr.c	(revision 110710)
+++ expr.c	(working copy)
@@ -2279,6 +2279,7 @@
      superclass chain when we're BC-compiling.  */
   if (! flag_verify_invocations
       && method
+      && ! TYPE_ARRAY_P (self_type)
       && self_type != DECL_CONTEXT (method))
     method = NULL_TREE;
Comment 11 Tom Tromey 2006-02-08 16:04:57 EST
I've CC'd Andrew Overholt.

Using "-target 1.3" by default can be bad, at least if Eclipse does this
strictly.  The difference from 1.3->1.4 was a relaxation in verifier semantics
so that 'this$0' could be initialized before the super <init> is called.
Without this some code calling an outer class method during initialization
can NPE.

A strict "1.3" compliance setting (at least in the abstract, I did not
check ecj) will generate code that does this -- it has to, because a
1.3 VM will not verify code that sets the this$0 field early.
Comment 12 Andrew Haley 2006-02-09 09:09:23 EST
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26192
Comment 13 Jakub Jelinek 2006-02-20 13:29:26 EST
Should be fixed in gcc-4.1.0-0.27 then.

Note You need to log in before you can comment on or make changes to this bug.