A few observations: The TestBreakpoints test contains three subordinate tests: testHitAndRun, testInsertRemove, and testAddLots, occurring in the source file and run in that order. What's happening is that the first of these tests, testHitAndRun, passes, the second, testInsertRemove, locks up as described above. The first oddity is that if you comment out the testHitAndRun test, testInsertRemove passes and testAddLots fails. If you comment out testHitAndRun and testInsertRemove, testAddLots passes, as does the whole test: [0] (moller@hotbox) >./TestRunner frysk.proc.TestBreakpoints 23:34:32 Running testAddLots(frysk.proc.TestBreakpoints) ... setUp to.at ao.at ao.ua to.ut tearDown PASS Time: 0.127 OK (1 test) All those setUp, to.at... things are from System.out.println() stmts I put in the code--the ao.xx prints are from the AttachedObserver method (or is it a class? Java ain't my thing...); to.xx are from TerminatingObserver. Now, here's what happens if I turn all the tests back on: [0] (moller@hotbox) >./TestRunner frysk.proc.TestBreakpoints 23:47:56 Running testHitAndRun(frysk.proc.TestBreakpoints) ... setUp starting testHitAndRun, attached = false h-and-r about to ao. h-and-r done ao. h-and-r addattached. ao.at to.at ao.ua to.ut ending testHitAndRun tearDown PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ... setUp starting testInsertRemove, attached = false ir about to ao. ir done ao. ir addattached. wait for attach, attached = false Exception in thread "Thread-6" java.lang.RuntimeException: {frysk.proc.LinuxTask@4d7300,pid=6697,tid=6697,state=detached} in state "detached" did not handle handleTerminatedEvent Notice that while the testHitAndRun test gets the ao.xx and to.xx stuff after setting up AttachedObserver and TerminatingObserver, the following testInsertRemove test /doesn't/ get them. The problem isn't caused by out-of-order stuff, it's caused by a complete failure of the second AttachedObserver and TerminatingObserver. Why this fails, I don't know yet. I suspect you could get the tests to pass individually by splitting them across three separate TestWhatever.java files, but I don't know if that would be cheating--will the circumstances set up in these tests ever actually occur together in the real world?
This was an actual problem in the test-setup in frysk. Although it is a little strange it never happens on FC5. Theoretically it could though. Problem should have been fixed upstream CVS by: 2006-08-21 Mark Wielaard <mark> * TestBreakpoints.java: Implements Observer. (procTerminated): New boolean field. (setup): Add observableProcRemoved to manager.host. (tearDown): Make sure proc is really gone. (update): New method. And refined today by Andrew Casey: 2006-08-22 Andrew Cagney <cagney> * TestLib.java (tearDown): For terminated threads, re-reap their pid. * TestBreakpoints.java (tearDown): Delete code using the event loop to reap children. (setUp): Do not add to Manager .host .observableProcRemovedXXX .addObserver. With either of these patches this passes for me now on FC6t2: [mark@hermans ~]$ cat /etc/redhat-release Fedora Core release 5.91 (FC6 Test2) [mark@hermans ~]$ uname -a Linux hermans.wildebeest.org 2.6.17-1.2583.fc6 #1 SMP Tue Aug 22 00:29:50 EDT 2006 i686 i686 i386 GNU/Linux [mark@hermans frysk-core]$ ./TestRunner frysk.proc.TestBreakpoints Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Time: 0.393 OK (3 tests)
Fixed in current build.