Created attachment 10293 [details]
Simplified test case (this will become a jar)

Compile the attached minimalistic test case into a jar file:

tar xzf test.tar.gz
gcj -C org/arklinux/test/testcase.java
fastjar cf test.jar org/arklinux/test/*.class org/arklinux/test/*.properties

Created attachment 10294 [details]
Testcase, part 2

Step 2: Compile something that uses it

CLASSPATH=test.jar gcj -C test1.java

Step 3: Try running it.

CLASSPATH=test.jar gij test1

Prints "Microsoft is crap" with gcj 4.0.x, produces a segmentation fault with today's SVN.

Also try:

gcj -O2 -fPIC -fjni -shared -o libtestcase.so test.jar
gcj -o testcase test1.java --main=test1 -L. -ltestcase
LD_LIBRARY_PATH=. ./testcase

Works as expected in 4.0.x, current SVN acts up: Generating libtestcase.so doesn't produce an error, but after that things get strange.

$ gcj -o testcase test1.java --main=test1 -L. -ltestcase
test1.java:1: error: Can't find default package 'org.arklinux.test'. Check the CLASSPATH environment variable and the access to the archives
1 error
test1.java:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions

Similar error if I tell it where to find the jar:
$ CLASSPATH=test.jar gcj -o testcase test1.java --main=test1 -L. -ltestcase
test1.java:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions

This should be marked important regression IMO, it breaks a number of applications out there

I tried the included test case with current svn head.
I had to add '.' to classpath, then it worked for me:

opsy. CLASSPATH=test.jar:. gij test1
Microsoft is crap

Compiling as in comment #4 also worked fine.

I also tried with the 4.1 branch (updated and built today)
and this also worked fine.

Not sure what to do next ... does it still fail for you?
If you add . to CLASSPATH, does it work?

If that works then perhaps the crash is EH related, as I see
an exception if I leave out '.'.

Just tried current 4.1 branch SVN (108424 with the patch for bug 24441 applied) - it works a lot better (no more ICEs or segfaults).
One problem remains though (but this isn't major):

CLASSPATH=test.jar gij test1

Still doesn't work, but it doesn't crash anymore - and actually produces a reasonable error message:

Exception in thread "main" java.lang.NoClassDefFoundError: test1
   <<No stacktrace available>>
Caused by: java.lang.ClassNotFoundException: test1 not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:test.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   <<No stacktrace available>>


Adding . to the CLASSPATH variable helps, but this wasn't necessary with older gcj versions (3.4.x, 4.0.x), so the new behavior will probably break some scripts. (Guess the older versions implied classpath . for the class specified on the command line).

Not sure which behavior is more correct though.

Adjusting summary to reflect the current situation

After some more testing, it turns out the test case is fixed, but the bigger test case from the original report isn't.

Compiling ecj with gcj 4.0.1 and using it on a simple .java file still causes a SIGABRT after strace indicates an attempt to open org/eclipse/jdt/internal/compiler/parser/readableNames.class
(when there's just a readableNames.properties)

Created attachment 10460 [details]
Script to trigger the SIGABRT problem

Attaching a script that still triggers the SIGABRT.

It's quite large for a test case (since it downloads parts of ecj CVS), but triggers the bug 100% reliably at least on my setups (and works perfectly if gcj, gij and fastjar are from gcc 4.0.x)

After adding some debug statements, I can add that the SIGABRT happens in org.eclipse.jdt.internal.compiler.parser.Parser's readReadableNameTable method.

ResourceBundle.getBundle() succeeds [doesn't throw a MissingResourceException, which is odd because strace clearly shows it looking in the wrong place (.class instead of .properties), but maybe the bundle is indeed found after accessing a nonexistant class file (maybe the lookup order should be changed?)].

A couple of lines later, the line "String n = bundle.getString(name[i]);" triggers the SIGABRT.

The code doesn't get past the line, and doesn't enter the MissingResourceException handler either.

Created attachment 10511 [details]
Small test case

Found a MUCH smaller test case, just a couple of lines.

tar xzf testcase.tar.gz; cd testcase; ./crashme

triggers the SIGABRT in 21 lines of code.

Created attachment 10512 [details]
Another, even smaller, testcase

Attaching another even smaller test case.

This happens 100% reproducably when using ResourceBundle.getString on an existing bundle with a nonexistant key -- this is enough to reproduce, no need for an external jar or anything:

===============================
import java.util.*;
class test {
        public static void main(String args[]) {
                ResourceBundle bundle=ResourceBundle.getBundle("gnu.java.locale.LocaleInformation");
                bundle.getString("This key does not exist.");
        }
}
===============================


Note that using getObject instead of getString works.

Created attachment 10515 [details]
Workaround patch

The problem is with implicit exception handling.

A slight modification to libjava (making the exception explicit) "fixes" it and makes all the problematic code (including the full ecj) work.

Patch attached, but unless my understanding of Java exceptions is wrong (which might be, given I'm a C/C++ programmer), this just hides the effects of the real problem.

I tried the new reduced test case from comment #13, using
my svn trunk build.  It worked fine.

I suspect something in your configuration is triggering a gcc
bug -- i.e., that it is not really a "java" problem but instead
some latent bug.

How are you configuring?  I didn't use any particularly unusual arguments,
just --enable-languages=c,c++,java and --enable-java-awt=gtk,xlib.

Might be my {C,CXX}FLAGS...

I can reproduce this on Linux 2.6.15, glibc 2.3.6, binutils 2.16.91.0.4, gcc 4.1 branch (SVN Revision 108760) with

--enable-fast-install --enable-libstdcxx-pch --enable-__cxa_atexit --enable-c99 --enable-wchar_t --enable-tls --enable-cxx-flags="-O2 -march=i586 -mcpu=i686 -fomit-frame-pointer -fweb -frename-registers" --with-system-zlib --enable-java-awt=gtk --enable-interpreter --enable-hash-synchronization --enable-languages=c,cxx,java,ada,fortran,objc

I'll try with some of those disabled.

If I compile without the compiler flag settings and make bootstrap instead of profiledbootstrap, it throws the exception as expected rather than causing a SIGABRT.

The cause is probably somewhere else in gcc; 4.0.2 works with the CFLAGS etc. I normally use.

Closing 4.1 branch.

Closing 4.2 branch.

GCC 4.3.4 is being released, adjusting target milestone.

GCC 4.3.5 is being released, adjusting target milestone.

4.3 branch is being closed, moving to 4.4.7 target.

Is this still an issue?

4.4 branch is being closed, moving to 4.5.4 target.

No feedback since January on this really old bug -> resolved
(as INVALID for lack of a better option).