This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix pldd not to leave process stopped after detaching
- From: Pedro Alves <palves at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 29 Aug 2013 10:18:20 +0100
- Subject: Re: [PATCH] Fix pldd not to leave process stopped after detaching
- Authentication-results: sourceware.org; auth=none
- References: <mvm7gf7h0qy dot fsf at hawking dot suse dot de>
On 08/27/2013 11:44 AM, Andreas Schwab wrote:
> When attaching to a process we always have to wait for the tracee to
> enter ptrace-stop state. Otherwise this can result in a race where the
> STOP signal is reveived after we have already detached from it again,
> leaving the process in stopped state.
Won't this hang with job stopped processes?
gdb has this to handle that scenario (linux_nat_post_attach_wait):
if (linux_proc_pid_is_stopped (pid)) // this is a /proc/PID/status check
{
if (debug_linux_nat)
fprintf_unfiltered (gdb_stdlog,
"LNPAW: Attaching to a stopped process\n");
/* The process is definitely stopped. It is in a job control
stop, unless the kernel predates the TASK_STOPPED /
TASK_TRACED distinction, in which case it might be in a
ptrace stop. Make sure it is in a ptrace stop; from there we
can kill it, signal it, et cetera.
First make sure there is a pending SIGSTOP. Since we are
already attached, the process can not transition from stopped
to running without a PTRACE_CONT; so we know this signal will
go into the queue. The SIGSTOP generated by PTRACE_ATTACH is
probably already in the queue (unless this kernel is old
enough to use TASK_STOPPED for ptrace stops); but since SIGSTOP
is not an RT signal, it can only be queued once. */
kill_lwp (pid, SIGSTOP);
/* Finally, resume the stopped process. This will deliver the SIGSTOP
(or a higher priority signal, just like normal PTRACE_ATTACH). */
ptrace (PTRACE_CONT, pid, 0, 0);
}
--
Pedro Alves