When calling Manager.host.requestCreateAttachedProc() and handling the resulting return from the AttachedObserver; adding an InstructionObserver to the Task, removing the AttachedObserver, and then attemping to step appears to never return from the EventLoop.
(FC6 x86_64)
I think I see the problem. When we ask to step onto the very first instruction for some reason the stepping debug flag isn't set in the isa debug registers. This means we interpret the trap event as a real trap signal which we pass on to the process which gets instantly killed...
why does fstep work? It goes through the same sequence. Or if it isn't it would be a bug :-)
Added a simplified test and a first workaround for this issue. 2007-06-20 Mark Wielaard <mwielaard@redhat.com> * frysk-core/frysk/proc/Observation.java (toString): Include observable and observer. * frysk-core/frysk/proc/Task.java (just_started): New boolean field. * frysk-core/frysk/proc/TestTaskObserverInstruction.java (testFirstInstructionStep): New test) (StepAttachedObserver): New inner class. (testFirstInstructionSteppingEngine): Renamed method from testFirstInstructionStep. Remove broken marker. 2007-06-20 Mark Wielaard <mwielaard@redhat.com> * frysk-core/frysk/proc/ptrace/LinuxTaskState.java (blockOrAttachContinue): Set just_started marker. (sendContinue): Reset just_started marker unless first step. (Running.handleTrapped): Check and reset just_started marker. Keeping open to resolve with a real Stepping state and after consulting on other debug step marker corner cases.
(In reply to comment #3) > why does fstep work? It goes through the same sequence. Or if it isn't it > would be a bug :-) That is a good question. The only difference is that in the case of the failing test the attached observer blocks first and then immediately gets unblocked after the instruction observer is installed, while in the fstep case all observers always return CONTINUE. This difference makes fstep miss the first few instructions of the process, and so not triggering this bug. Oddly enough it seems to start almost always at the same one, but running it often enough does show some randomness in the starting address. Created a new bug #4668
I mentioned earlier to Andrew that this problem doesn't happen in the SourceWidow after performing a brief 'continue', and then stepping, which appears to replicate the case with fstep.
(In reply to comment #4) > Keeping open to resolve with a real Stepping state and after consulting on other > debug step marker corner cases. Done. There is now a Stepping state which is a subclass of Running.