Bug 24698

Summary: [4.6/4.7/4.8 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
Product: gcc Reporter: bero
Component: javaAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: normal CC: gcc-bugs, java-prs
Priority: P5    
Version: 4.1.0   
Target Milestone: 4.6.4   
Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu Known to work: 3.4.4, 3.4.5, 4.0.0, 4.0.1, 4.0.2, 4.0.3
Known to fail: 4.1.0, 4.2.0 Last reconfirmed: 2012-01-11 00:00:00
Attachments: Simplified test case (this will become a jar)
Testcase, part 2
Script to trigger the SIGABRT problem
Small test case
Another, even smaller, testcase
Workaround patch

Description bero 2005-11-06 19:53:14 UTC
Sorry for the vague description and huge test case - I don't speak Java beyond the "it looks a lot like C++" level.

Trying to use a gcj 4.1 SVN rev 106562-compiled ecj (built using the workaround from bug 24441) results in a SIGABRT when trying to translate any .java file (even a simple helloworld.java).

strace-ing the output indicates it can't locate the compiler messages, which are in messages.properties, which is definitely included in the .jar and the .jar is in the classpath. Looks like gcj/gij look for a messages.class file instead.
Relevant parts of strace output:
* open("/usr/lib/libeclipse-ecj.so", O_RDONLY) = 3
<--- It finds the precompiled version [the problem doesn't go away if I delete that and use the .jar only]
* stat64("/usr/share/java/eclipse-ecj.jar", {st_mode=S_IFREG|0644, st_size=905576, ...}) = 0
* open("/usr/share/java/eclipse-ecj.jar", O_RDONLY|O_LARGEFILE) = 9
<--- It finds and reads the jar file nevertheless
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* access("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so", R_OK) = -1 ENOENT (No such file or directory)
* access("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so", R_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages_en_US.so", O_RDONLY) = -1 ENOENT (No such file or directory)
* access("/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages_en.properties", F_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("lib-org-eclipse-jdt-internal-compiler-batch-messages.la", O_RDONLY) = -1 ENOENT (No such file or directory)
* access("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so", R_OK) = -1 ENOENT (No such file or directory)
* access("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so", R_OK) = -1 ENOENT (No such file or directory)
* open("/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so", O_RDONLY) = -1 ENOENT (No such file or directory)
* open("/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-messages.so", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/home/arklinux/./org/eclipse/jdt/internal/compiler/batch/messages.class", F_OK) = -1 ENOENT (No such file or directory)
<--- It looks for org.eclipse.jdt.internal.compiler.batch.messages* in various places without finding anything, insisting it's supposed to be a .class when it's in fact looking for messages.properties

[strace-ing the 4.0.x generated version confirms messages.properties is what it's looking for].

$ jar tfv eclipse-ecj.jar |grep compiler/util/messages
  2764 Wed Jan 12 00:13:34 CET 2005 org/eclipse/jdt/internal/compiler/util/messages.properties


The same code (and build process) works nicely if gcj/gij 4.0.x is used.
Comment 1 bero 2005-11-19 15:00:25 UTC
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
Comment 2 bero 2005-11-19 15:02:11 UTC
Created attachment 10294 [details]
Testcase, part 2

Step 2: Compile something that uses it

CLASSPATH=test.jar gcj -C test1.java
Comment 3 bero 2005-11-19 15:03:19 UTC
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.
Comment 4 bero 2005-11-19 15:16:33 UTC
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
Comment 5 bero 2005-11-24 18:07:31 UTC
This should be marked important regression IMO, it breaks a number of applications out there
Comment 6 Tom Tromey 2005-11-29 22:37:08 UTC
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 '.'.
Comment 7 bero 2005-12-12 19:16:53 UTC
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.
Comment 8 bero 2005-12-12 19:18:42 UTC
Adjusting summary to reflect the current situation
Comment 9 bero 2005-12-12 20:02:24 UTC
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)
Comment 10 bero 2005-12-12 21:00:50 UTC
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)
Comment 11 bero 2005-12-16 01:01:20 UTC
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.
Comment 12 bero 2005-12-16 01:17:34 UTC
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.
Comment 13 bero 2005-12-16 01:24:57 UTC
Created attachment 10512 [details]
Another, even smaller, testcase

Attaching another even smaller test case.
Comment 14 bero 2005-12-16 09:59:14 UTC
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.
Comment 15 bero 2005-12-16 13:22:28 UTC
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.
Comment 16 Tom Tromey 2006-01-08 18:41:36 UTC
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.
Comment 17 bero 2006-01-08 21:50:39 UTC
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.
Comment 18 bero 2006-01-17 18:25:43 UTC
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.
Comment 19 Joseph S. Myers 2008-07-04 20:06:51 UTC
Closing 4.1 branch.
Comment 20 Joseph S. Myers 2009-03-31 19:01:01 UTC
Closing 4.2 branch.
Comment 21 Richard Biener 2009-08-04 12:27:14 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 22 Richard Biener 2010-05-22 18:10:46 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 23 Richard Biener 2011-06-27 12:13:30 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 24 Richard Biener 2012-01-11 14:50:50 UTC
Is this still an issue?
Comment 25 Jakub Jelinek 2012-03-13 12:46:23 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 26 Steven Bosscher 2012-11-09 22:52:39 UTC
No feedback since January on this really old bug -> resolved
(as INVALID for lack of a better option).