gcj segfaults on i686/x86_64-apple-darwin*

gcj segfaults on i686/x86_64-apple-darwin*

[Jack Howarth]

    Do any of the gcc java developers have access to intel darwin?
We are seeing segfaults on i686-apple-darwin9/10 and x86_64-apple-darwin9/10
when compiling code like...

public class testme { 
  public static void main(String args[]){ 
    System.out.println("Hello"); 
  } 
} 

with "gcj --main=testme -O testme.java" which produces segfaults of the
form...

gcj: Internal error: Abort trap (program ecj1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

This failure is showing up on x86_64-apple-darwin9/10 for gcc 4.4.2
and gcc trunk. Interestingly, i686-apple-darwin9 doesn't show the
segfault for gcc 4.4.2 but does for gcc trunk. Both gcc 4.4.2 and
gcc trunk show the segfault for i686-apple-darwin10. The gcc compiler
with ftp://sourceware.org/pub/java/ecj-latest.jar in the top level
of the build directory to produce the ecj1 binary. The gcc configurations
are of the form...

../gcc-4.5-20091107/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --with-arch=nocona --with-tune=generic
--build=i686-apple-darwin9 --host=i686-apple-darwin9
--target=i686-apple-darwin9

This issue has been filed as PR41991.
            Jack
ps Using -v to figure out how ecj1 is called, I obtained the following backtrace
under gcc trunk...

gdb /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
...
(gdb) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
Starting program: /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1 testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
Reading symbols for shared libraries ++++.+. done

Program received signal SIGABRT, Aborted.
0x94cc2e42 in __kill ()
(gdb) bt
#0  0x94cc2e42 in __kill ()
#1  0x94cc2e34 in kill$UNIX2003 ()
#2  0x94d3523a in raise ()
#3  0x94d41679 in abort ()
#4  0x038de502 in _Jv_Throw (value=<value temporarily unavailable, due to optimizations>) at ../../../gcc-4.5-20091107/libjava/exception.cc:128
#5  0x039359bb in _ZN4java4lang5Class7forNameEJPS1_PNS0_6StringES2_ (className=<value temporarily unavailable, due to optimizations>, caller=<value temporarily unavailable, due to optimizations>) at Class.java:133
Previous frame inner to this frame (gdb could not unwind past this frame)

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Andrew Haley]

Jack Howarth wrote:
>     Do any of the gcc java developers have access to intel darwin?

I don't think so.

> gdb /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
> ...
> (gdb) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
> Starting program: /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1 testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
> Reading symbols for shared libraries ++++.+. done
> 
> Program received signal SIGABRT, Aborted.
> 0x94cc2e42 in __kill ()
> (gdb) bt
> #0  0x94cc2e42 in __kill ()
> #1  0x94cc2e34 in kill$UNIX2003 ()
> #2  0x94d3523a in raise ()
> #3  0x94d41679 in abort ()
> #4  0x038de502 in _Jv_Throw (value=<value temporarily unavailable, due to optimizations>) at ../../../gcc-4.5-20091107/libjava/exception.cc:128
> #5  0x039359bb in _ZN4java4lang5Class7forNameEJPS1_PNS0_6StringES2_ (className=<value temporarily unavailable, due to optimizations>, caller=<value temporarily unavailable, due to optimizations>) at Class.java:133
> Previous frame inner to this frame (gdb could not unwind past this frame)

This is caused by incorrect unwind information being generated by gcc, or
by a bug in gcc's unwinder library.

Andrew.

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Jack Howarth]

On Mon, Nov 09, 2009 at 08:56:12AM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
>>     Do any of the gcc java developers have access to intel darwin?
>
> I don't think so.
>
>> gdb /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1
>> ...
>> (gdb) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
>> Starting program: /sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin9/4.5.0/ecj1 testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccCFc8VX.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccBrG88S.jar
>> Reading symbols for shared libraries ++++.+. done
>>
>> Program received signal SIGABRT, Aborted.
>> 0x94cc2e42 in __kill ()
>> (gdb) bt
>> #0  0x94cc2e42 in __kill ()
>> #1  0x94cc2e34 in kill$UNIX2003 ()
>> #2  0x94d3523a in raise ()
>> #3  0x94d41679 in abort ()
>> #4  0x038de502 in _Jv_Throw (value=<value temporarily unavailable, due to optimizations>) at ../../../gcc-4.5-20091107/libjava/exception.cc:128
>> #5  0x039359bb in _ZN4java4lang5Class7forNameEJPS1_PNS0_6StringES2_ (className=<value temporarily unavailable, due to optimizations>, caller=<value temporarily unavailable, due to optimizations>) at Class.java:133
>> Previous frame inner to this frame (gdb could not unwind past this frame)
>
> This is caused by incorrect unwind information being generated by gcc, or
> by a bug in gcc's unwinder library.
>
> Andrew.

Andrew,
   Shouldn't the libjava testsuite contain some rudimentary tests using gcj
to make sure it is functional? The recent testsuite results don't suggest
major problems with java on intel darwin...

http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html

                    Jack

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Andrew Haley]

Jack Howarth wrote:

>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
> to make sure it is functional?

Sure.

> The recent testsuite results don't suggest
> major problems with java on intel darwin...
> 
> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html

This means that, whatever the cause of the bug, it wasn't present
when these tests were run.

You can easily verify that yourself by running 'make check-target-libjava'.

Andrew.

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Jack Howarth]

On Mon, Nov 09, 2009 at 02:33:11PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
>
>>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
>> to make sure it is functional?
>
> Sure.
>
>> The recent testsuite results don't suggest
>> major problems with java on intel darwin...
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
>> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html
>
> This means that, whatever the cause of the bug, it wasn't present
> when these tests were run.
>
> You can easily verify that yourself by running 'make check-target-libjava'.
>
> Andrew.

Andrew,
   What exactly would I need to add to...

public class testme {
  public static void main(String args[]){
    System.out.println("Hello");
  }
}

to convert it into a libjava compilation/execution test case for gcj?
It might be simplier to just try to run such a test case from within
the libjava dejagnu harness to verify that the issue doesn't exist
within it. I was considering something like...

gcj --main=testme -O pr41991.java

for the compilation and a scan for Hello on the output of the
execution run. Thanks in advance for any hints on where to place
such a test within the libjava dejagnu tests and what header
entries to add.
                Jack

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Andrew Haley]

Jack Howarth wrote:
> On Mon, Nov 09, 2009 at 02:33:11PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>
>>>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
>>> to make sure it is functional?
>> Sure.
>>
>>> The recent testsuite results don't suggest
>>> major problems with java on intel darwin...
>>>
>>> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
>>> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html
>> This means that, whatever the cause of the bug, it wasn't present
>> when these tests were run.
>>
>> You can easily verify that yourself by running 'make check-target-libjava'.
>>
>> Andrew.
> 
> Andrew,
>    What exactly would I need to add to...
> 
> public class testme {
>   public static void main(String args[]){
>     System.out.println("Hello");
>   }
> }
> 
> to convert it into a libjava compilation/execution test case for gcj?

you need to add one file, testme.out, which contains the expected
output from testme.  Put both files in libjava/testsuite/libjava.lang.

> It might be simplier to just try to run such a test case from within
> the libjava dejagnu harness to verify that the issue doesn't exist
> within it. I was considering something like...
> 
> gcj --main=testme -O pr41991.java
> 
> for the compilation and a scan for Hello on the output of the
> execution run. Thanks in advance for any hints on where to place
> such a test within the libjava dejagnu tests and what header
> entries to add.

I find it very hard to believe that the rest of the tests would pass
while Hello, world fails.

Andrew.

Re: gcj segfaults on i686/x86_64-apple-darwin*

[David Daney]

Andrew Haley wrote:
> Jack Howarth wrote:
> 
>>    Shouldn't the libjava testsuite contain some rudimentary tests 
>> using gcj
>> to make sure it is functional?
> 
> Sure.
> 

Do you mean something like libjava.lang/Array_3?

David Daney

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Jack Howarth]

On Mon, Nov 09, 2009 at 02:33:11PM +0000, Andrew Haley wrote:
> Jack Howarth wrote:
>
>>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
>> to make sure it is functional?
>
> Sure.
>
>> The recent testsuite results don't suggest
>> major problems with java on intel darwin...
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
>> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html
>
> This means that, whatever the cause of the bug, it wasn't present
> when these tests were run.
>
> You can easily verify that yourself by running 'make check-target-libjava'.
>
> Andrew.

Andrew,
   Actually the nature of the testsuite will mask this failure on intel darwin.
The gcj compiler doesn't segfault when presented with a *.class file to compile
into an executable. Only when presented a *.java file will the gcj compiler abort.
The output to libjava.log suggests that all of the tests in libjava.lang are executed
via the class file contained in the associated jar file rather than compiling directly
the java file itself. 

Running /sw/src/fink.build/gcc45-4.4.999-20091107/gcc-4.5-20091107/libjava/testsuite/libjava.lang/lang.exp ...
set_ld_library_path_env_vars: ld_library_path=.:/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs
Executing on host: /sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/./gcc/gcj -B/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/ -B/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/./gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include    --encoding=UTF-8 -B/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/../ /sw/src/fink.build/gcc45-4.4.999-20091107/gcc-4.5-20091107/libjava/testsuite/libjava.lang/ArrayStore.jar  -w  -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute --main=ArrayStore -g  -L/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs -lm   -o /sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/ArrayStore.exe    (timeout = 300)
PASS: ArrayStore compilation from source
set_ld_library_path_env_vars: ld_library_path=.:/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs
invoke: /sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/ArrayStore.exe  
Setting LD_LIBRARY_PATH to .:/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs:.:/sw/src/fink.build/gcc45-4.4.999-20091107/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs
java.lang.ArrayIndexOutOfBoundsException
java.lang.ArrayStoreException
java.lang.ArrayIndexOutOfBoundsException
foobar
PASS: ArrayStore execution - source compiled test
PASS: ArrayStore output - source compiled test

I suspect if the libjava harness was fixed to compile the java files if a ecj1 was
built that all of the libjava.lang tests would suddenly fail on darwin.
             Jack

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Andrew Haley]

Jack Howarth wrote:
> On Mon, Nov 09, 2009 at 02:33:11PM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>
>>>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
>>> to make sure it is functional?
>> Sure.
>>
>>> The recent testsuite results don't suggest
>>> major problems with java on intel darwin...
>>>
>>> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
>>> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html
>> This means that, whatever the cause of the bug, it wasn't present
>> when these tests were run.
>>
>> You can easily verify that yourself by running 'make check-target-libjava'.

>    Actually the nature of the testsuite will mask this failure on intel darwin.
> The gcj compiler doesn't segfault when presented with a *.class file to compile
> into an executable. Only when presented a *.java file will the gcj compiler abort.

In that case, gcj isn't aborting.  gcj only ever compiles .class -> .o, where
.java -> .class compilation is performed by ecj1.

> I suspect if the libjava harness was fixed to compile the java files if a ecj1 was
> built that all of the libjava.lang tests would suddenly fail on darwin.

Andreas Tobler Seems to think it's to do with stack execution, but
I can't understand how that can be: gcj doesn't generate executable
code on the stack.

Andrew.

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Andreas Tobler]

Andrew Haley wrote:
> Jack Howarth wrote:
>> On Mon, Nov 09, 2009 at 02:33:11PM +0000, Andrew Haley wrote:
>>> Jack Howarth wrote:
>>>
>>>>    Shouldn't the libjava testsuite contain some rudimentary tests using gcj
>>>> to make sure it is functional?
>>> Sure.
>>>
>>>> The recent testsuite results don't suggest
>>>> major problems with java on intel darwin...
>>>>
>>>> http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00666.html
>>>> http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01308.html
>>> This means that, whatever the cause of the bug, it wasn't present
>>> when these tests were run.
>>>
>>> You can easily verify that yourself by running 'make check-target-libjava'.
> 
>>    Actually the nature of the testsuite will mask this failure on intel darwin.
>> The gcj compiler doesn't segfault when presented with a *.class file to compile
>> into an executable. Only when presented a *.java file will the gcj compiler abort.
> 
> In that case, gcj isn't aborting.  gcj only ever compiles .class -> .o, where
> .java -> .class compilation is performed by ecj1.

That is what I told you, Andrew, on #irc.

>> I suspect if the libjava harness was fixed to compile the java files if a ecj1 was
>> built that all of the libjava.lang tests would suddenly fail on darwin.
> 
> Andreas Tobler Seems to think it's to do with stack execution, but
> I can't understand how that can be: gcj doesn't generate executable
> code on the stack.

Gcj not, but what is with ecj1? The suggestion I posted to the PR 
affects the ecjx linking.

The patchlet I posted in the 41991 PR does allow me to compile a java 
file into a class file and execute it with gij. Also the same for java 
to binary compile. This was not the case before. I went back to Jan 31 
09 and I always got an Abort with ecj1.

Note beside, I always installed the built gcc and tested the installed 
binaries.

[deuterium:~] andreast% gcj -C hello.java
[deuterium:~] andreast% gij hello
Hello World
Hello Andreas

[deuterium:~] andreast% gcj --main=testme -O testme.java
[deuterium:~] andreast% ./a.out
Hello

[deuterium:~] andreast% gcj -v
Using built-in specs.
Reading specs from 
/Volumes/development/gcc/head/testbin-x86_64/lib/gcc/x86_64-apple-darwin9/4.5.0/../../../libgcj.spec
  rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
COLLECT_LTO_WRAPPER=/Volumes/development/gcc/head/testbin-x86_64/libexec/gcc/x86_64-apple-darwin9/4.5.0/lto-wrapper
Target: x86_64-apple-darwin9
Configured with: /Volumes/development/gcc/head/gcc/configure 
--prefix=/Volumes/development/gcc/head/testbin-x86_64 
--build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 
--disable-static --with-gmp=/usr/local/x86_64 
--with-mpfr=/usr/local/x86_64 --enable-java-awt=xlib 
--enable-languages=c,c++,java
Thread model: posix
gcc version 4.5.0 20091111 (experimental) [trunk revision 153973] (GCC)


I'll run some more tests.

Andreas

Re: gcj segfaults on i686/x86_64-apple-darwin*

[Jack Howarth]

On Fri, Nov 13, 2009 at 12:17:45AM +0100, Andreas Tobler wrote:
>
> The patchlet I posted in the 41991 PR does allow me to compile a java  
> file into a class file and execute it with gij. Also the same for java  
> to binary compile. This was not the case before. I went back to Jan 31  
> 09 and I always got an Abort with ecj1.
>
> Note beside, I always installed the built gcc and tested the installed  
> binaries.
>
> [deuterium:~] andreast% gcj -C hello.java
> [deuterium:~] andreast% gij hello
> Hello World
> Hello Andreas
>
> [deuterium:~] andreast% gcj --main=testme -O testme.java
> [deuterium:~] andreast% ./a.out
> Hello
>
> [deuterium:~] andreast% gcj -v
> Using built-in specs.
> Reading specs from  
> /Volumes/development/gcc/head/testbin-x86_64/lib/gcc/x86_64-apple-darwin9/4.5.0/../../../libgcj.spec
>  rename spec startfile to startfileorig
> rename spec lib to liborig
> COLLECT_GCC=gcj
> COLLECT_LTO_WRAPPER=/Volumes/development/gcc/head/testbin-x86_64/libexec/gcc/x86_64-apple-darwin9/4.5.0/lto-wrapper
> Target: x86_64-apple-darwin9
> Configured with: /Volumes/development/gcc/head/gcc/configure  
> --prefix=/Volumes/development/gcc/head/testbin-x86_64  
> --build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9  
> --disable-static --with-gmp=/usr/local/x86_64  
> --with-mpfr=/usr/local/x86_64 --enable-java-awt=xlib  
> --enable-languages=c,c++,java
> Thread model: posix
> gcc version 4.5.0 20091111 (experimental) [trunk revision 153973] (GCC)
>
>
> I'll run some more tests.
>
> Andreas
>

Andreas,
   I'll try the proposed patch under x86_64-apple-darwin9 this weekend.
It wouldn't be a huge surprise if it worked as darwin10 has subsumed
libgcc into libSystem. Thus under darwin10, the system unwinder is
always in use (rather that the one in FSF libgcc as is the case under darwin9).
              Jack