[kaffe] Re: circular linking difficulties
Rob Gonzalez
rgonzale at wso.williams.edu
Tue Jun 29 06:16:17 PDT 2004
Hi Helmer,
Are you sure that the problem we see there isn't that UnknownElement is in
the midst of linking when that checkMethodCall() call is made?
ProjectComponent is stored in that block as an Hjava_lang_Class* (you can
tell by the (16)), while UnknownElement is stored as a signature (the
(4)), which means that UnknownElement must be resolved before type
checking can occur. If you put the following line at the top of
resolveType() in verify-type.c you may find that the failure is in a
getClassFromSigature() call, as I suspect it might be (that is,
getClassFromSignature fails to load the type, so it returns NULL, so NULL
is stored, etc. etc.):
DBG(VERIFY3, dprintf("%s trying to resolve: ", indent);
printType(t); dprintf("\n"); );
The checkMethodCall() is the first method that actually posts an exception
in the list of methods called during the type checking of a method return
type, the previous ones in the verifier simply return NULL, and the
loadClass() stuff fills in values of einfo without dying.
What are you running ant 1.6.0 on? Just any old build file? I want to
reproduce it so I can see the whole debugging trace (which I assume is way
too big to post here).
Rob
On Tue, 29 Jun 2004, Helmer [ISO-8859-15] Krämer wrote:
> On Mon, 28 Jun 2004 17:17:35 -0400 (EDT)
> rob at kaffe.org wrote:
>
> Hi Rob,
>
> > > What puzzles me is that we already have the CSTATE_DOING_LINK phase
> > > during class loading, which seems to be what you want
> > [ rest of paragraph deleted ]
> >
> > I agree, but it doesn't seem to be working. Kaffe is definitely choking
> > when a getClassFromSignature call calles loadClass to be called on a class
> > that is in the process of verification already. I have no idea why the
> > CSTATE_DOING_LINK isn't working...
>
> I'm pretty sure that we'll find out what's going wrong here ;)
>
> When running ant 1.6.0, I get the following error:
>
> considering method org/apache/tools/ant/Task.getReplacement()Lorg/apache/tools/ant/UnknownElement;
> verifying method getReplacement
> [...]
> blockNum/first pc/changed/stksz = 1 / 7 / 1 / 0
> before:
> locals:
> 0: (16)org/apache/tools/ant/Task
> opstack (0):
> 0: (0)TUNSTABLE
> 1: (0)TUNSTABLE
> 2: (0)TUNSTABLE
> 3: (0)TUNSTABLE
> about to verify the block...
> block->startAddr = 7, block->lastAddr = 127, first instruction = 42
> [...]
> pc = 30, opcode = 182 == INVOKEVIRTUAL
> calling method setProject(Lorg/apache/tools/ant/Project;)V
> typechecking (16)org/apache/tools/ant/ProjectComponent vs. (4)Lorg/apache/tools/ant/UnknownElement;
> required receiver type: (16)org/apache/tools/ant/ProjectComponent
> actual receiver type: (16)NULL
> error with method invocation, pc = 30, method = setProject(Lorg/apache/tools/ant/Project;)V
>
> some problem with a method call...here's the block:
> locals:
> 0: (16)org/apache/tools/ant/Task
> opstack (2):
> 0: (16)NULL
> 1: (4)Lorg/apache/tools/ant/Project;
> 2: (0)TUNSTABLE
> 3: (0)TUNSTABLE
> Verify Method 3b: org/apache/tools/ant/Task.getReplacement()Lorg/apache/tools/ant/UnknownElement;: FAILED
> cleaning up... done
>
> Since ProjectComponent is a super class of UnknownElement, the typecheck
> should succeed. Exactly why this error leads to a ClassCircularityError
> later on, is another interesting question.
>
> Regards,
> Helmer
>
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>
More information about the kaffe
mailing list