Hello, On Tue, Mar 15, 2011 at 01:26:16AM +0300, Dmitry V. Levin wrote: > Well, it's in some peculiar state that it is not running, and > nothing but SIGKILL or > PTRACE_CONT/PTRACE_SYSCALL/PTRACE_SINGLESTEP/PTRACE_DETACH can > change it. If you say it's not trapped, then I don't know what the > trapped state is. :)
The first one is a ptrace signal delivery trap which wouldn't have happened if the task weren't being traced. It's basically telling the tracer that the tracee is about to get the signal delivered and asking what the debugger wants to do about it, to which strace(2) answers to deliver the signal. The second one is the job control stop. If not for ptrace, the task would stop in the 'stopped' state and would respond to SIGCONT and SIGKILL. Under ptrace, well, it first enters the 'stopped' state but gets moved into 'traced' (debug trap) state by ptrace request. This is changing and the tracee will enter 'traced' state directly. So, the stop is a debug trap but it is implementing the job control stop and kernel will add mechanism for strace to notice that job control stop has finished and resume the tracee accordingly, so for strace's purpose, I think it would be more precies to report it as job control stop, which strace currently overrides unconditionally (as it doesn't have any other option). Thanks. -- tejun ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
