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

[Patrick Tullmann]

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

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
                Your research fills a much needed gap.