[Bug libgcj/20169] Serialization: readResolve does not work
--- Additional Comments From bonniot at users dot sf dot net 2005-05-27 09:47 --- FYI, my patch for solving this bug in classpath is https://savannah.gnu.org/patch/index.php?func=detailitemitem_id=3893 My copyright assignment is on its way... I cannot comment on the current behaviour of gcc, as my nightly build seems borked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug libgcj/21785] New: [regression] ClassNotFound during deserialization
This very simple serialization/deserialization test fails. This is a regression.
import java.io.*;
public class Enum implements Serializable
{
public static void main(String[] args)
{
try {
ByteArrayOutputStream outb = new ByteArrayOutputStream();
ObjectOutputStream outs = new ObjectOutputStream(outb);
outs.writeObject(new Enum());
byte[] store = outb.toByteArray();
ByteArrayInputStream inb = new ByteArrayInputStream(store);
ObjectInputStream ins = new ObjectInputStream(inb);
ins.readObject();
}
catch (Throwable e) {
throw new Error(e);
}
}
}
///
sauternes /tmp /usr/local/src/gcc-cvs/install/bin/gcj -C Enum.java
[04:54 27/05/05]
sauternes /tmp /usr/local/src/gcc-cvs/install/bin/gij Enum
[04:54 27/05/05]
Exception in thread main java.lang.Error: java.lang.ClassNotFoundException:
Enum
at Enum.main (Enum.java:17)
Caused by: java.lang.ClassNotFoundException: Enum
at java.lang.Class.forName (natClass.cc:91)
at java.io.ObjectInputStream.resolveClass (ObjectInputStream.java:782)
at java.io.ObjectInputStream.readClassDescriptor (ObjectInputStream.java:534)
at java.io.ObjectInputStream.readObject (ObjectInputStream.java:228)
at java.io.ObjectInputStream.readObject (ObjectInputStream.java:275)
at Enum.main (Enum.java:15)
sauternes /tmp kaffe Enum
[04:54 27/05/05]
sauternes /tmp java Enum
sauternes /tmp
gij (GNU libgcj) version 4.1.0 20050527 (experimental)
Note: this bug looks similar to a bug I reported against jamvm:
https://sourceforge.net/tracker/?func=detailatid=543058aid=1155738group_id=75148
I paste here the evaluation Robert sent me privately after he fixed it, as it
MIGHT be relevant to gcj too (being a change in classpath).
P.S. It was the recent changes made to Classpath.
VMSecurityManager.currentClassLoader() now returns null if
checkPermissions(AllPermissions) passes. ObjectInputStream uses this
to resolve a class, and ends up trying to resolve it using the
bootstrap class loader (which fails). By luck SableVM works, because
it doesn't have a complete implementation of VMAccessController, so
checkPermissions(AllPermissions) fails, and currentClassLoader returns
the same as before. I'll report a Classpath/SableVM bug.
--
Summary: [regression] ClassNotFound during deserialization
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonniot at users dot sf dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785
[Bug libgcj/20169] Serialization: readResolve does not work
--- Additional Comments From bonniot at users dot sf dot net 2005-05-27 15:05 --- The new behaviour is caused by PR21785, which currently masks this bug. -- What|Removed |Added BugsThisDependsOn||21785 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug libgcj/21785] [regression] ClassNotFound during deserialization
-- What|Removed |Added OtherBugsDependingO||20169 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785
[Bug java/18362] [4.0 Regression] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From bonniot at users dot sf dot net 2005-03-05 21:02 --- Verified. The patch works for me. (I can't really set to verified since I'm not the original submitter) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug libgcj/20169] Serialization: readResolve does not work
--- Additional Comments From bonniot at users dot sf dot net 2005-03-02 22:11 --- Submitting the mauve testcases, with a classpath patch on the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From bonniot at users dot sf dot net 2005-03-02 00:11 --- What's the take on this bug? Can indirect-dispatch be made the default in the foreseable future? Can the old verifier be fixed? I'm now running nightly builds of gcj on the Nice compiler testsuite (1250 testcases). There are currently 11 failures, and 4 seem to be instances of this verifier bug. So fixing this would be a great improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug java/20215] New: gcj does not accept classes with same name fields
According to the JVM spec, class files can have several fields with the same name. As long as they have different types, they will be distinguished since all field operations specify both the name and the field of the field. Sun's JVM accepts such classes, and correctly distinguishes the fields, as you can see in the attached testcase. Here is the disassembly of this class: Access flags: 0x20 super This class: 2=DuplicateField, super: 4=java.lang.Object Interfaces (count: 0): Fields (count: 2): Field name:foo static Signature: 6=java.lang.String Field name:foo static Signature: 7=int Methods (count: 3): Method name:init Signature: 9=()void Attribute Code, length:17, max_stack:1, max_locals:1, code_length:5 0: aload_0 1: invokespecial #11=Method java.lang.Object.init ()void 4: return Method name:main public static Signature: 14=(java.lang.String[])void Attribute Code, length:31, max_stack:2, max_locals:1, code_length:19 0: getstatic #20=Field java.lang.System.out java.io.PrintStream 3: getstatic #22=Field DuplicateField.foo java.lang.String 6: invokevirtual #28=Method java.io.PrintStream.println (java.lang.String)void 9: getstatic #20=Field java.lang.System.out java.io.PrintStream 12: getstatic #30=Field DuplicateField.foo int 15: invokevirtual #33=Method java.io.PrintStream.println (int)void 18: return Method name:clinit static Signature: 9=()void Attribute Code, length:24, max_stack:1, max_locals:0, code_length:12 0: ldc #36=String WOW 2: putstatic #22=Field DuplicateField.foo java.lang.String 5: sipush 42 8: putstatic #30=Field DuplicateField.foo int 11: return Sun's JVM correctly executes that program: $ java DuplicateField WOW 42 gcj fails during compilation with: $ gcj DuplicateField.class DuplicateField.java: In class 'DuplicateField': DuplicateField.java: In method 'DuplicateField.main(java.lang.String[])': DuplicateField.java:0: error: mismatching signature for field 'foo' in 'DuplicateField' DuplicateField.java: In method 'DuplicateField.clinit()': DuplicateField.java:0: error: mismatching signature for field 'foo' in 'DuplicateField' Surprisingly, gij also fails with: Exception in thread main java.lang.NullPointerException at java.io.PrintStream.println(java.lang.String) (/tmp/gcc/lib/libgcj.so.6.0.0) at DuplicateField.main(java.lang.String[]) (Unknown Source) at gnu.java.lang.MainThread.call_main() (/tmp/gcc/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/tmp/gcc/lib/libgcj.so.6.0.0) gcj (GCC) 4.0.0 20050223 -- Summary: gcj does not accept classes with same name fields Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonniot at users dot sf dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20215
[Bug java/20215] gcj does not accept classes with same name fields
--- Additional Comments From bonniot at users dot sf dot net 2005-02-25 19:50 --- Created an attachment (id=8285) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8285action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20215
[Bug libgcj/20169] Serialization: readResolve does not work
--- Additional Comments From bonniot at users dot sf dot net 2005-02-26 01:35 --- After some investigation, I think I understand what is going wrong. It seems like readResolve is only called if it is declared in the deserialized object's class. However, it should also be searched for in the classes's parents, provided the method there is visible (that is, normal rules apply). I submitted a related testcase to mauve: http://sources.redhat.com/ml/mauve-patches/2005/msg00032.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug java/20169] New: Serialization: readResolve does not work
I attach a simple Java class, which exercises the readResolve method. An object
is serialzed and deserialized from a byte array. Because of the readResolve
method, the object read back should be the exact same instance. This works with
JDK, but fails with both gij and gcj, as of today. It also fails with other free
runtimes: kaffe (1.1.4.PRECVS8) and jamvm (1.2.3), so it could be a GNU
classpath issue.
Here is the testcase:
///
import java.io.*;
public abstract class Enum implements Serializable
{
static Enum instance;
Object readResolve() {
return instance;
}
static class Color extends Enum
{
static final Color red = new Color();
static { instance = red; }
}
public static void main(String[] args)
{
try {
ByteArrayOutputStream outb = new ByteArrayOutputStream();
ObjectOutputStream outs = new ObjectOutputStream(outb);
outs.writeObject(Color.red);
byte[] store = outb.toByteArray();
ByteArrayInputStream inb = new ByteArrayInputStream(store);
ObjectInputStream ins = new ObjectInputStream(inb);
Color color = (Color) ins.readObject();
System.out.println(color);
System.out.println(Color.red);
System.out.println(color == Color.red);
}
catch (Throwable e) {
throw new Error(e);
}
}
}
//
Here is what happens:
/tmp/gcc/bin/gcj -C Enum.java
JDK: java Enum
[EMAIL PROTECTED]
[EMAIL PROTECTED]
true
GIJ: LD_LIBRARY_PATH=/tmp/gcc/lib /tmp/gcc/bin/gij Enum
[EMAIL PROTECTED]
[EMAIL PROTECTED]
false
GCJ: /tmp/gcc/bin/gcj --main=Enum *.class
LD_LIBRARY_PATH=/tmp/gcc/lib ./a.out
[EMAIL PROTECTED]
[EMAIL PROTECTED]
false
/tmp/gcc/bin/gcj --version
gcj (GCC) 4.0.0 20050223 (experimental)
--
Summary: Serialization: readResolve does not work
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonniot at users dot sf dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i386-debian-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug java/20056] [4.0 regression] 'verification failed: incompatible type on stack' with --indirect-dispatch
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23 16:06 --- I verified the bytecode testcase now passes. Thanks for the fix! (is it final now?) -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20056
[Bug java/18362] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23 17:10 --- Patch works for me on the small testcase (N.jar). I'll try on the whole jar when I get the chance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug java/18362] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From bonniot at users dot sf dot net 2005-02-23 17:40 --- I tried the patched gcj on the whole jar (containing the Nice compiler), and this error does not occur (nor any other, yay!). As far as I can tell, Andrew's patch fixes this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug java/20056] New: [4.0 regression] 'verification failed: incompatible type on stack' with --indirect-dispatch
The testcase is a tiny bytecode class. gcj 3.3 and 3.4 can compile it, and the bcel verifier says it is valid. However, gcj 4.0.0 fails on it when --indirect-dispatch is enabled: $ /usr/lib/gcc-snapshot/bin/gcj --indirect-dispatch test/ACatch.class test/main.nice: In class 'test.ACatch': test/main.nice: In constructor '(test.Monotype)': test/main.nice:1: error: verification failed: incompatible type on stack -- Summary: [4.0 regression] 'verification failed: incompatible type on stack' with --indirect-dispatch Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonniot at users dot sf dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i386-debian-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20056
[Bug java/20056] [4.0 regression] 'verification failed: incompatible type on stack' with --indirect-dispatch
--- Additional Comments From bonniot at users dot sf dot net 2005-02-18 14:53 --- Created an attachment (id=8226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8226action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20056
[Bug java/18362] internal compiler error: in size_binop, at fold-const.c:1598
--- Additional Comments From bonniot at users dot sf dot net 2005-02-18 16:48 --- Created an attachment (id=8228) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8228action=view) testcase This is a 6K jar that exhibits the same behaviour: $ /usr/lib/gcc-snapshot/bin/gcj --indirect-dispatch N.jar bossa/syntax/ast.nice:0: internal compiler error: in size_binop, at fold-const.c:1637 That's with gcj 4.0.0 20050212. Note that if you remove any of the three classes from the jar, the bug does not occur. Neither does it if you unpack the jar and call gcj on the three classes directly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug java/18362] internal compiler error: in size_binop, at fold-const.c:1598
-- What|Removed |Added CC||bonniot at users dot sf dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18362
[Bug java/20031] New: [4.0 regression] ICE on missing files
I'm getting two different ICEs in certain compilation situations, with trivially small files. This seems to be about where source/class files are located, not what's inside them (although the second bug does only occur if class B has the abstract modifier). Instead of painfully explaining what exacts steps to take to reproduce, I included a small Makefile in the archive. This is a regression: I get the ICEs with gcj 4.0.0 20050212 (Debian gcc-snapshot), while both gcj 3.3 and 3.4 work correctly (report errors, without ICE). -- Summary: [4.0 regression] ICE on missing files Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonniot at users dot sf dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i386-debian-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug java/20031] [4.0 regression] ICE on missing files
--- Additional Comments From bonniot at users dot sf dot net 2005-02-17 16:55 --- Created an attachment (id=8215) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8215action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug java/20031] [4.0 regression] ICE on missing files
--- Additional Comments From bonniot at users dot sf dot net 2005-02-17 16:57 --- I forgot, here is the output I get: /usr/lib/gcc-snapshot/bin/gcj -d classes -C pkg/A.java pkg/B.java /usr/lib/gcc-snapshot/bin/gcj classes/pkg/B.class jc1: 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. make: [bug1] Error 1 (ignored) mv pkg pkg.bak /usr/lib/gcc-snapshot/bin/gcj classes/pkg/B.class jc1: error: cannot find file for class pkg.A pkg/B.java:0: error: cannot find file for class pkg.A pkg/B.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. make: [bug2] Error 1 (ignored) mv pkg.bak pkg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug java/20044] New: Wrong method call semantics (maybe instanceof/invokespecial)
This is a very small testcase, in which the code generated by gcj does not behave correctly at runtime. I set the severity as critical because there is no notification that something went wrong while the wrong method gets called, and I see no workaround. I suppose that there is a problem either with an instanceof test, or with the implementation of invokespecial. Feel free to update the summary if this turns out to be the wrong intuitition. Attached are three small bytecode classes (I could not reproduce the bug from Java sources). # Normal behaviour, using Sun's JDK $ java test.fun true $ gcj --main=test.fun test/*.class $ ./a.out false Tested with gcj 4.0.0 20050212. -- Summary: Wrong method call semantics (maybe instanceof/invokespecial) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonniot at users dot sf dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i386-debian-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
--- Additional Comments From bonniot at users dot sf dot net 2005-02-17 23:49 --- Created an attachment (id=8219) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8219action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
