Re: ATF tests hanging

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 27,  7:53pm, martin%duskware.de@localhost (Martin Husemann) wrote:
-- Subject: Re: ATF tests hanging

| On Wed, Dec 27, 2017 at 02:51:38PM +0100, Martin Husemann wrote:
| > On Wed, Dec 27, 2017 at 08:42:52AM -0500, Christos Zoulas wrote:
| > > Well, it is not failing on sparc64, that's the issue.
| > 
| > It is not expected to fail, but it is failing. The tracer process waits
| > for the child but the child does not exit - maybe the PT_CONTINUE did
| > not work or whatever.
| 
| I am trying to understand what the test does. It still makes no sense to
| me and I completely fail to see how it can work anywhere.
| 
| The test forks a child process and then:
| 
| 	child:
| 	 - ptrace(PT_TRACE_ME...)
| 	 - blocks SIGTRAP
| 	 - raises SIGSTOP
| 	 - does a MD breakpoint instruction
| 	 - exits
| 
| apparently after assuming the tracing (parent) process has skipped the
| breakpoint instruction.
| 
| 	parent:
| 	 - waits for the child process to notify it of the SIGSTOP signal
| 	 - ptrace(PT_CONTINUE, ..., (void *)1, ..)
| 
| that is: continue where it left of, i.e. right on the breakpoint
| instruction. A real debugger would have removed the breakpoint
| instruction and replaced it by the original code (or suply a new value
| for %pc as address argument), but in this test this does not happen, so
| the child should hit a breakpoint right away again.
| 
| I must be missing something, or the test works on alpha and x86 due to a
| bug, but correctly fails on other architectures.

I agree with the assessment.

christos