|Summary:||TaskObserver.Instruction doesn't appear to unblock on new process' first instructions|
|Product:||frysk||Reporter:||Mike Cvet <mcvet>|
|Component:||general||Assignee:||Mark Wielaard <mark>|
|Bug Depends on:|
|Bug Blocks:||3346, 4668|
Description Mike Cvet 2007-06-19 21:06:13 UTC
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.
Comment 1 Mike Cvet 2007-06-19 21:26:23 UTC
Comment 2 Mark Wielaard 2007-06-20 12:23:16 UTC
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...
Comment 3 Andrew Cagney 2007-06-20 15:12:39 UTC
why does fstep work? It goes through the same sequence. Or if it isn't it would be a bug :-)
Comment 4 Mark Wielaard 2007-06-20 15:18:54 UTC
Added a simplified test and a first workaround for this issue. 2007-06-20 Mark Wielaard <email@example.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 <firstname.lastname@example.org> * 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.
Comment 5 Mark Wielaard 2007-06-20 15:52:37 UTC
(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
Comment 6 Mike Cvet 2007-06-20 15:55:59 UTC
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.