I must have run 'make check' 50 times, testing something else before this popped up: Running testInsertRemove(frysk.proc.TestBreakpoints) ...Exception in thread "Thread-25" java.lang.NullPointerException at frysk.proc.Breakpoint.set(TestRunner) at frysk.proc.Breakpoint.install(TestRunner) at frysk.proc.TaskState$BlockedSignal.handleAddCodeObserver(TestRunner) at frysk.proc.Task.handleAddCodeObserver(TestRunner) at frysk.proc.TaskCodeObservation.handleAdd(TestRunner) at frysk.proc.ProcState$3.handleAddObservation(TestRunner) at frysk.proc.Proc.handleAddObservation(TestRunner) at frysk.proc.Proc$10.execute(TestRunner) at frysk.event.EventLoop.runEventLoop(TestRunner) at frysk.event.EventLoop.run(TestRunner) at frysk.proc.TestBreakpoints$EventLoopRunner.run(TestRunner)
Confirmed on x86_64 also. After lots of runs (./TestRunner -r 1000 frysk.proc.TestBreakpoints)
The behaviour has changed. Now testInsertRemove hangs, but doesn't show the exception. This seems to be some bad interaction with an execedEvent. But it is hard to trigger with -c FINE logs.
We weren't properly waiting till the code observer was installed and so an ExecedEvent could happen before the observer was properly installed. Fixed by: 2007-01-15 Mark Wielaard <mark@klomp.org> Fixes bug #3240 * TestBreakPoints.java (testInsertRemove): Make sure the observer is properly installed. Now ./TestRunner -r 1000 frysk.proc.TestBreakpoints still fails as follows: Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...ERROR pipe (24) Time: 0.428 There was 1 error: 1) testAddLots(frysk.proc.TestBreakpoints)pipe (24) at frysk.testbed.ForkTestLib.throwErrno(TestRunner) at frysk.testbed.ForkTestLib.fork(TestRunner) at frysk.proc.TestBreakpoints.setUp(TestRunner) at frysk.junit.Runner.runCases(TestRunner) at frysk.junit.Runner.runArchCases(TestRunner) at frysk.junit.Runner.runTestCases(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 3, Failures: 0, Errors: 1 Failed after run #168 But this is always after #168 runs (on either a single processor x86 and a multi-core x86_64. And I believe this is actually bug #3863 (libunwind leaking).