0

According to the ptrace documentation.

Stop the tracee at the next clone(2) and automatically start tracing the newly cloned process, which will start with a SIGSTOP, or PTRACE_EVENT_STOP if PTRACE_SEIZE was used.

The problem is that SIGSTOP may not be caused by ptrace at all - even the user can send this signal to the process. Child process being stopped by PTRACE_EVENT_STOP would be more than perfect in this case.

I'm spawning a child process myself so using PTRACE_TRACEME is the best way to start tracing it - it's free of race conditions. If I insist on using PTRACE_SEIZE instead, the child process may have already exited before I call PTRACE_SEIZE in the parent process.

Is there any way to prevent the child process from receiving a plain SIGSTOP when tracing with PTRACE_TRACEME?

marmistrz
  • 5,974
  • 10
  • 42
  • 94

1 Answers1

0

In a nutshell, you can't.

There is good news, however. Since Linux version 3.4, ptrace supports a new operation, PTRACE_SEIZE. It is from the parent rather than the child, so the attach semantics are somewhat different. Other than that, it has a few differences, one of which is that it solves this particular problem.

You will need to read the man page to get the gory details. Pretty much everything about the way events are reported has changed if you use it. This problem (along with similar ones) is precisely the reason it was introduced, so if that problem bothers you, you should definitely use PTRACE_SEIZE instead of PTRACE_TRACEME, despite the inconvenience.

Shachar Shemesh
  • 8,193
  • 6
  • 25
  • 57