[Bug java/24698] New: [4.1 regression] Apparent problem getting non-.class files out of jars

[Bug java/24698] New: [4.1 regression] Apparent problem getting non-.class files out of jars

[bero at arklinux dot org]

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.


-- 
           Summary: [4.1 regression] Apparent problem getting non-.class
                    files out of jars
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bero at arklinux dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars

[bero at arklinux dot org]

------- Comment #1 from bero at arklinux dot org  2005-11-19 15:00 -------
Created an attachment (id=10293)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10293&action=view)
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars

[bero at arklinux dot org]

------- Comment #2 from bero at arklinux dot org  2005-11-19 15:02 -------
Created an attachment (id=10294)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10294&action=view)
Testcase, part 2

Step 2: Compile something that uses it

CLASSPATH=test.jar gcj -C test1.java


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars

[bero at arklinux dot org]

------- Comment #3 from bero at arklinux dot org  2005-11-19 15:03 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars

[bero at arklinux dot org]

------- Comment #4 from bero at arklinux dot org  2005-11-19 15:16 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] Failure locating .properties files inside jars

[bero at arklinux dot org]

------- Comment #5 from bero at arklinux dot org  2005-11-24 18:07 -------
This should be marked important regression IMO, it breaks a number of
applications out there


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.1.0 4.2.0
      Known to work|                            |3.4.4 3.4.5 4.0.0 4.0.1
                   |                            |4.0.2 4.0.3
            Summary|[4.1/4.2 regression]        |[4.1/4.2 regression] Failure
                   |Apparent problem getting    |locating .properties files
                   |non-.class files out of jars|inside jars


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] Failure locating .properties files inside jars

[tromey at gcc dot gnu dot org]

------- Comment #6 from tromey at gcc dot gnu dot org  2005-11-29 22:37 -------
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 '.'.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] Failure locating .properties files inside jars

[bero at arklinux dot org]

------- Comment #7 from bero at arklinux dot org  2005-12-12 19:16 -------
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.


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #8 from bero at arklinux dot org  2005-12-12 19:18 -------
Adjusting summary to reflect the current situation


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 regression] Failure|[4.1/4.2 regression]
                   |locating .properties files  |CLASSPATH . no longer
                   |inside jars                 |implied for class specified
                   |                            |on the command line


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #9 from bero at arklinux dot org  2005-12-12 20:02 -------
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)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #10 from bero at arklinux dot org  2005-12-12 21:00 -------
Created an attachment (id=10460)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10460&action=view)
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)


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10293|0                           |1
        is obsolete|                            |
  Attachment #10294|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #11 from bero at arklinux dot org  2005-12-16 01:01 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #12 from bero at arklinux dot org  2005-12-16 01:17 -------
Created an attachment (id=10511)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10511&action=view)
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.


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10460|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when trying to read properties files from jars; and CLASSPATH . no longer implied for class specified on the command line

[bero at arklinux dot org]

------- Comment #13 from bero at arklinux dot org  2005-12-16 01:24 -------
Created an attachment (id=10512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10512&action=view)
Another, even smaller, testcase

Attaching another even smaller test case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[bero at arklinux dot org]

------- Comment #14 from bero at arklinux dot org  2005-12-16 09:59 -------
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.


-- 

bero at arklinux dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[bero at arklinux dot org]

------- Comment #15 from bero at arklinux dot org  2005-12-16 13:22 -------
Created an attachment (id=10515)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10515&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[tromey at gcc dot gnu dot org]

------- Comment #16 from tromey at gcc dot gnu dot org  2006-01-08 18:41 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[bero at arklinux dot org]

------- Comment #17 from bero at arklinux dot org  2006-01-08 21:50 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[bero at arklinux dot org]

------- Comment #18 from bero at arklinux dot org  2006-01-17 18:25 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.1/4.2/4.3 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.2/4.3/4.4 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[jsm28 at gcc dot gnu dot org]

------- Comment #19 from jsm28 at gcc dot gnu dot org  2008-07-04 20:06 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 regression]|[4.2/4.3/4.4 regression]
                   |SIGABRT when using          |SIGABRT when using
                   |ResourceBundle.getBundle    |ResourceBundle.getBundle
                   |with a nonexistant key      |with a nonexistant key
   Target Milestone|4.1.3                       |4.2.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.3/4.4/4.5 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[jsm28 at gcc dot gnu dot org]

------- Comment #20 from jsm28 at gcc dot gnu dot org  2009-03-31 19:01 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 regression]|[4.3/4.4/4.5 regression]
                   |SIGABRT when using          |SIGABRT when using
                   |ResourceBundle.getBundle    |ResourceBundle.getBundle
                   |with a nonexistant key      |with a nonexistant key
   Target Milestone|4.2.5                       |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.3/4.4/4.5 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2009-08-04 12:27 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698

[Bug java/24698] [4.3/4.4/4.5/4.6 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-05-22 18:10 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698