[kaffe] completed bytecode verifier!

[Rob Gonzalez]

Hi Tim & Helmer,

I've been toying with the circular error for a while now and have only
ruled out solutions.  I tried Helmer's idea to have a special getClass()
and it didn't seem to work, Tim's reservations notwithstanding.

I suspect that he may be right about breaking up the loading of
superclasses with an extra CSTATE, but my attempts to get that to work
also did not pan out.

Rob


On Fri, 8 Aug 2003, Timothy Stack wrote:

> > Hi Tim,
> 
> hi,
> 
> > I think I managed to figure out what is going wrong here.
> > Hopefully my explanations will not get too confusing.
> 
> Thanks, I understood it just fine.
> 
> > First of all, you might consider applying the attached patch,
> > since it will give you some better error messages in case some
> > type could not be resolved during verification (do you know why
> > getClassFromSignature throws away the einfo from classFromSig?).
> 
> Its broken...  It should return NULL immediately if classFromSig fails to 
> load the class.  And the check for "consuming all characters in string" 
> should be done by the verifier.  And, it might leak memory since it 
> doesn't call discardErrorInfo...  Anyways...
> 
> > If you try running $JAVA at.dms.kjc.CSourceClass afterwards,
> > you will see that kaffe thinks that it has detected a
> > ClassCircularityError.
> > 
> > Now comes the confusing part, since I'll try to explain what
> > I think is going on here ;)
> > 
> > First of all, CSourceClass is derived from CClass, which is derived
> > from CMember (all in package at.dms.kjc). So when kaffe has to load
> > CSourceClass, that will trigger loading CClass and loading CClass in
> > turn will trigger loading CMember. This will cause kaffe to process
> > CMember to state CSTATE_LINKED, while CSourceClass and CClass are
> > both in the CSTATE_LOADED_SUPER state (and their classMappingState
> > is NMS_LOADING).
> > 
> > Processing CMember to CSTATE_LINKED however, includes verifcation
> > of the class CMember (both, verify2 and verify3). But in order to
> > do this, the verifier has to resolve the types CSourceClass and
> > CClass (they are needed for type checking during verification of
> > the getAccessorOwner method). Since the verifier uses loadClass()
> > to resolve the type, the ClassCircularityError is thrown (because
> > classMappingSearch detects that the state is NMS_LOADING and that
> > the current thread is responsible for it).
> > 
> > Next problem is that the verifier needs a class that is at least
> > in state >= CSTATE_LOADED_SUPER (otherwise it could not check for
> > inheritance). 
> 
> > An idea how to fix this? My guess would be to defer verification
> > of the superclass until after the subclass is in state CSTATE_LOADED_SUPER
> > (and NMS_LOADED). This could probably be done by creating a special
> > getClass() that returns a class that is only CSTATE_PREPARED,
> 
> I don't think this will work with user loaders since getClass() calls
> loadClass(), which can call a user loader, which can do whatever it wants.
> 
> > but not
> > CSTATE_LINKED. The subclass would load the superclass using this special
> > getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING)
> > and process the superclass to CSTATE_LINKED afterwards. That way, the
> > verifier would be able to properly resolve the subclass while verifying
> > the superclass, but detection of ClassCircularityErrors should still
> > work?
> 
> I think the circularity checking is broken, its just checking to see if 
> there is a loop in calls to loadClass and not checking that its still 
> trying to load the super class.  For example, in this case CMember would 
> have finished loading its super (java.lang.Object) so there is no 
> circularity.
> 
> I'm thinking the fix would involve a new class state and classEntry state 
> that break up the loading of the super class.  I'll try to look at it more 
> over the weekend...
> 
> > Greetings,
> > Helmer
> 
> tim
> 
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>