[kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)

[Timothy Stack]

Patrick Tullmann wrote:

> I was reading the VM spec last night, and it says that the end of an
> exception range is exclusive, vs. the start being inclusive.  Since
> that's exactly what's happening (the exception is being re-tossed at
> the very end of the coverage), I changed:
> 	if (pc < start_pc || pc > end_pc) {
> 	       continue;
> 	}
> to:
> 	if (pc < start_pc || pc >= end_pc) {
> 	       continue;
> 	}
> in the loop over the available exception handlers in
> findExceptionBlockInMethod.  This "fixed" the problem.  However, that
> comparison hasn't been touched since December `98.  I have a hard time
> believing the interpreter has never encountered this situation
> before...  (Perhaps the end_pc's were fixed up elsewhere at some
> point?)
> 
> Hmm.... compiling it with kcj 'Version 2.1B released 17. July 2002' or
> jikes 'Version 1.13 3/1/2001' doesn't make any difference...  Also,
> Sun's JDK1.4 can complete either compiled version of the test just
> fine.

odd, i'm pretty sure it worked with a jikes v1.14 compiled file

> 
> So, I think that's the fix.  I'm still wary because I wonder why it
> ever worked... :)

noone uses intrp :)  Which raises the question, why does it work fine 
for the jitter and not intrp?

So, lets try and reexamine the whole thing...

First, what does the pc in the parameter list correspond to?  The 
current pc or the next pc?

For intrp, this gets set by runVirtualMachine intrp/machine.c:

		register uintp pc = npc;

		assert(npc < meth->c.bcode.codelen);
		mjbuf->pc = pc;
		npc = pc + insnLen[code[pc]];

and read by dispatchException in exception.c:

			/* Look for handler */
			res = findExceptionBlockInMethod(frame->pc, eobj->base.dtable->class, 
frame->meth, &einfo);

So, it uses the pc of the currently executing instruction...


For the jitter, this gets set by buildStackTrace in stackTrace.c:

		info[cnt].pc = STACKTRACEPC(trace);

and read by unwindStackFrame in exception.c:

	meth = findExceptionInMethod(frame->pc, class, &einfo);


So, it uses the return pc found in the stack trace, which corresponds to 
the next instruction to execute.  Oops...  Maybe we should change the 
intrp engine to set mjbuf->pc to npc and see if that fixes it.


Also, grepping for "end_pc" turns up this code in checkCaughtExceptions 
in jit/machine.c

		/* include only if exception handler range matches pc */
		if (meth->exception_table->entry[i].start_pc > pc ||
		    meth->exception_table->entry[i].end_pc <= pc)
			continue;

Now, that doesn't look right to me...

> -Pat

tim stack