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

[Timothy Stack]

On Tuesday, September 17, 2002, at 02:57  AM, Patrick Tullmann wrote:

>>> But, I think its having problems because Kaffe is hanging in the
>>> ThreadInterrupt test.  There is a ThreadInterrupt.fail in both intrp
>>> trees that contains only:
>>>
>>> 	Success 0a.
>>
>> Yep, this is consistently repeatable on my Linux/x86 box (with 
>> intrp-debug).
>
> I've made a bit of progress on this bug.  First, I'll note that
> running with '-vmdebug ELOOKUP' is wicked handy!  It shows all the
> exceptions that are thrown and where they're caught.  The
> ThreadInterrupt tests seems to be getting into an infinite loop of
> exception dispatches:
>
>   dispatchException(): java/lang/InterruptedException
>   java/lang/Thread.waitOn has no handlers.
>   java/lang/Thread.sleep has 2 handlers (throw was pc=0x2b):
>     Handler 0 covers 0x25-0x31
>     Found handler @ 0x31: catches all exceptions.
>   dispatchException(): java/lang/InterruptedException
>   java/lang/Thread.sleep has 2 handlers (throw was pc=0x37):
>     Handler 0 covers 0x25-0x31
>     Handler 1 covers 0x31-0x37
>     Found handler @ 0x31: catches all exceptions.
>   dispatchException(): java/lang/InterruptedException
>   java/lang/Thread.sleep has 2 handlers (throw was pc=0x37):
>     Handler 0 covers 0x25-0x31
>     Handler 1 covers 0x31-0x37
>     Found handler @ 0x31: catches all exceptions.
> <This repeats for all eternity.>
>
> The particular test being run starts a thread in a 5s sleep, then
> starts a second thread to do a 1s sleep, then interrupt the first
> thread.  The above trace is for the 5s sleeping thread (at least, I'm
> pretty sure it is).  The interrupt is delivered correctly, but the
> subsequent exception doesn't make it out of Thread.sleep.  I believe
> the catch-all handler in Thread.sleep is the end of the
> synchronization block around the waitOn() call.
>
> I haven't had a chance to look at the interpreter's exception dispatch
> code, yet.  I was hoping this analysis might trigger some ah-ha moment
> in someone else...  :)  If not, I'll get back to this sooner or later.

I'm pretty sure this is kjc's fault, try compiling the test with jikes 
and comparing the byte code.  From what little i did with this it 
looked like kjc might be inadvertently generating the infinite loop in 
the exception handler.

> -Pat

tim stack