This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
- From: "thebohemian at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 18 Oct 2005 00:18:28 -0000
- Subject: [Bug libgcj/17021] libgcj verifier resolves classes too eagerly
- References: <bug-17021-6651@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #6 from thebohemian at gmx dot net 2005-10-18 00:18 -------
With the help of Tromey and the team we made an interesting obervation:
class Foo{
static Object o;
void method(){
o = new RemoveClassFile();
}
}
This is accepted by you-know-which VM but rejected by GIJ (processing putstatic
opcode in verify.cc leads to _Jv_BytecodeVerifier::ref_intersection::compatible
which in turn resolves the RHS).
Now takes this situation:
class Foo{
static Thread t;
void method(){
t = new RemoveClassFileFromClassWhichInheritsFromThread();
}
}
This is rejected by the 'other' verifier, too if no class file could be found.
The idea seems to be that the assignment test is short-cutted if the LHS is
Object.
Now we have to find and fix every situation where this can happen. Here is a
partial list:
- static assignment
- non-static assignment
- array assignment
- arguments to methods
- return values
- type state merges (only tromey knows what this is ;) )
*Important*:
If you have real world class files where this bug happens please send them to
me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021