Re: ptrace() hangs on attempt to seize/attach stopped & frozen task

From: Pedro Alves
Date: Thu Nov 19 2015 - 13:08:55 EST

On 11/19/2015 05:47 PM, Oleg Nesterov wrote:
> Thanks Pedro for your email,

>> 918 /* We need to wait for SIGSTOP before being able to make the next
>> 919 ptrace call on this LWP. */
>> 920 new_lwp->must_set_ptrace_flags = 1;
>> 921
>> 922 if (linux_proc_pid_is_stopped (lwpid))
> This can't happen today. Starting from v3.0 at least.

Eh, interesting. So right after PTRACE_ATTACH, we either observe
"running" or "ptrace-stopped", but never "job stopped". Correct?

I've actually just now tried this:

diff --git c/gdb/linux-nat.c w/gdb/linux-nat.c
index 841ec39..42f2b0d 100644
--- c/gdb/linux-nat.c
+++ w/gdb/linux-nat.c
@@ -981,6 +981,7 @@ linux_nat_post_attach_wait (ptid_t ptid, int first, int *cloned,
pid_t new_pid, pid = ptid_get_lwp (ptid);
int status;

+#if 0
if (linux_proc_pid_is_stopped (pid))
if (debug_linux_nat)
@@ -1006,6 +1007,7 @@ linux_nat_post_attach_wait (ptid_t ptid, int first, int *cloned,
(or a higher priority signal, just like normal PTRACE_ATTACH). */
ptrace (PTRACE_CONT, pid, 0, 0);

/* Make sure the initial process is stopped. The user-level threads
layer might want to poke around in the inferior, and that won't

and sure enough, gdb's test that covers that use case still
passes, on Fedora 20 (Linux 3.19.8).

And given that my Thunderbird crashed while writing this, I had sufficient
time to be sure that a full test run passes cleanly too. :-P :-)

>> But maybe not, if we're sure that
>> that when that happens, waitpid returns for the initial
> Yes. Just you can't assume that watpid(WNOHANG) will succeed. Is it OK?

Yes, assuming the ptracer is guaranteed to get a SIGCHLD to wake it up.

Pedro Alves
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at