On Thu, 7 Aug 2003 09:46:31 -0600 (MDT) Timothy Stack <[EMAIL PROTECTED]> wrote:
Hi Tim, > > I just committed the bytecode verifier. It's a huge chunk of code and > > it's very likely that there are little bugs lurking around in it...I can't > > even count how many off-by-one errors I had during development. > > make check-TESTS > make[1]: Entering directory `/z/stack/tmp0/kbuild/test/regression' > PASS: HelloWorldApp.class.save > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; > <<No stacktrace available>> > FAIL: HelloWorldApp.java > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; > <<No stacktrace available>> > FAIL: TestIntLong.java > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; > <<No stacktrace available>> I think I managed to figure out what is going wrong here. Hopefully my explanations will not get too confusing. 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?). 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, 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? Greetings, Helmer
emsg-patch
Description: Binary data
