gcj is not type-safe

Gary Benson gbenson@redhat.com
Thu Mar 22 16:24:00 GMT 2007


Gary Benson wrote:
> Tom Tromey wrote:
> > I think the bug here is that we don't implement the method loading
> > constraint mentioned in 5.4.2 (re-mentioned in 5.4.3.3):
> > 
> >    http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#71421
> > 
> > The reason I think this is that what happens here is that RT casts
> > one kind of R into the other -- because the getR method returns
> > one kind of R while RT directly references the other kind.  IOW,
> > the return type of getR is not validated according to the above
> > rule.
> > 
> > It turns out there's even a FIXME for this in
> > _Jv_Linker::resolve_method_entry.  So I would suggest fixing it
> > there.  We do implement this for fields, see
> > _Jv_Linker::find_field_helper.
> 
> Yeah, that would work.  Out of interest I modified my testcase to
> use a field rather than a method.  We catch it in find_field_helper,
> but Sun Java catches it in exactly the same way as it catches the
> dodgy method.  So the question is does the spec contain two ways to
> catch this just in a belt-and-braces kind of way, or is it that
> there are some things which slip past the method check and others
> which slip past the initiating loader check?  I guess more
> investigation is required...

While testing on a patch for this I realised there's two ways to spoof
a method: you can spoof the return type, like we're doing, or you can
spoof a parameter.  Spoofed return types and fields are caught in Sun
Java by the initiating loader check [1] but spoofed parameters are
caught explicitly [2], and if you spoof _both_ a parameter and the
return type then it's the parameter that gets caught.  So it looks
like they don't check the return type when they check the signature.

Cheers,
Gary

[1] java.lang.LinkageError: loader constraint violation: loader
    (instance of DelegatingLoader) previously initiated loading
    for a different type with name "R"

[2] java.lang.LinkageError: loader constraint violation: when
    resolving method "RR.putR(LR;)V" the class loader (instance
    of DelegatingLoader) of the current class, TT, and the class
    loader (instance of sun/misc/Launcher$AppClassLoader) for
    resolved class, RR, have different Class objects for the type
    R used in the signature



More information about the Java mailing list