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 _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
