This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: Stepping over signals, in state "detaching" did not handle handleStoppedEvent SIGTRAP(5)
- From: Andrew Cagney <cagney at redhat dot com>
- To: Nurdin Premji <npremji at redhat dot com>
- Cc: frysk <frysk at sources dot redhat dot com>
- Date: Tue, 29 Apr 2008 19:02:37 -0400
- Subject: Re: Stepping over signals, in state "detaching" did not handle handleStoppedEvent SIGTRAP(5)
- References: <481767EA.6050204@redhat.com>
I suspect that this:
// System.err.println("BreakPoint.addedTo");
- ((Task) observable).requestDeleteInstructionObserver(this.steppingEngine.getSteppingObserver());
+ Task task = (Task) observable;
+ this.steppingEngine.requestRemoveSteppingObserver(task);
is likely at least part of the problem - I see it's also pre-existing code. Breakpoints shouldn't be rooting around in the stepping engine.
+
+ public void stepOverSignal(Task task) {
+ DebugInfoFrame frame = DebugInfoStackFactory
+ .createDebugInfoStackTrace(task);
+
+ long address = frame.getAddress();
+
+ fine.log(this, "Looking for address: 0x", Long.toHexString(address), "Line #: ", frame.getLine().getLine());
+
+ TaskStepEngine tse = (TaskStepEngine) this.taskStateMap.get(task);
+ tse.setState(new StepOutState(task));
+ this.steppingObserver.notifyNotBlocked(tse);
+
+ int i = ((Integer) this.contextMap.get(task.getProc())).intValue();
+ this.contextMap.put(task.getProc(), new Integer(++i));
what I believe is happening is that this code:
+
+ this.breakpoint = new SteppingBreakpoint(this, address);
is removing the stepping-engine's observer before this:
+ this.breakpointMap.put(task, this.breakpoint);
+ task.requestAddCodeObserver(this.breakpoint, address);
has had a chance to install the breakpoint.
A better sequence is:
-> create breakpoint
-> request add breakpoint
-> request remove stepping observer
I believe Teresa was also looking at this.
Andrew
PS: Can the test-case be changed to assembler? As C it is going to run into portability problems.
+ }
Nurdin Premji wrote:
Here is current work on stepping over a signal, the race condition
involved is:
inside frysk-core:
./TestRunner -debug frysk.stepping.SteppingEngine=FINE
frysk.stepping.TestStepping.testStepOverSignal
There was 1 error:
1)
testStepOverSignal(frysk.stepping.TestStepping)java.lang.RuntimeException:
{frysk.proc.live.LinuxPtraceTask@327b6455,pid=29497,tid=29497,state=detaching}
in state "detaching" did not handle handleStoppedEvent SIGTRAP(5)
at frysk.proc.live.State.unhandled(TestRunner)
at
frysk.proc.live.LinuxPtraceTaskState$2.handleStoppedEvent(TestRunner)
at frysk.proc.live.LinuxPtraceTask.processStoppedEvent(TestRunner)
at frysk.proc.live.LinuxWaitBuilder.stopped(TestRunner)
at frysk.sys.Wait.wait(TestRunner)
at frysk.sys.Wait.wait(TestRunner)
at frysk.event.WaitEventLoop.block(TestRunner)
at frysk.event.EventLoop.runEventLoop(TestRunner)
at frysk.event.EventLoop.runPolling(TestRunner)
at frysk.testbed.TestLib.assertRunUntilStop(TestRunner)
at frysk.testbed.TestLib.assertRunUntilStop(TestRunner)
at frysk.stepping.TestStepping.testStepOverSignal(TestRunner)
at frysk.junit.Runner.runCases(TestRunner)
at frysk.junit.Runner.runTestCases(TestRunner)
at TestRunner.main(TestRunner)
happens quite frequently but every once in a while get a pass