[kaffe] completed bytecode verifier!

[Helmer Krämer]

On Fri, 8 Aug 2003 10:22:58 -0600 (MDT)
Timothy Stack <stack at cs.utah.edu> wrote:

Hi,

> > 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.

Hmm. I thought that a user loader would either return whatever defineClass()
returns (when loadClass is called with resolve==false) or what resolveClass()
returns (when loadClass is called with resolve==true). Therefore, I thought
that we could indeed predict what's returned by a user loader. So it seems
I'm once again missing something?
 
> > 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...

Sounds like you'll have a busy weekend, then ;)

Greetings,
Helmer