Bug 4663

Summary: TaskObserver.Instruction doesn't appear to unblock on new process' first instructions
Product: frysk Reporter: Mike Cvet <mcvet>
Component: generalAssignee: Mark Wielaard <mark>
Status: RESOLVED FIXED    
Severity: normal CC: mark, mcvet
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
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
(FC6 x86_64)
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  <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. 
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.
Comment 7 Mark Wielaard 2007-08-20 10:30:31 UTC
(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.