I was looking through this patch in Google Breakpad, and it changes how they wait for a thread to be stopped after attaching to it via ptrace(). In short, there might be a race between the SIGSTOP signal sent when suspending a thread and what we get in the following waitpid(). The different signals that might fall between the two syscalls can get lost, and the thread won't behave correctly once resumed, as it will eventually be stopped again.
I was looking through this patch in Google Breakpad, and it changes how they wait for a thread to be stopped after attaching to it via
ptrace(). In short, there might be a race between theSIGSTOPsignal sent when suspending a thread and what we get in the followingwaitpid(). The different signals that might fall between the two syscalls can get lost, and the thread won't behave correctly once resumed, as it will eventually be stopped again.