[lkml]   [2013]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectptrace(PTRACE_ATTACH) [no intervering wait] ptrace(PTRACE_DETACH) may leave tracee stuck
I received a report that glibc:elf/pldd hangs occasionally, and indeed..

for i in `seq 1 1000`; do taskset -c 3 pldd $$ > /dev/null 2>&1; done

..will do so. Rummage.....

ptrace(PTRACE_DETACH) returns -ESRCH when the trap hasn't happened yet,
which happens because pldd doesn't wait() before ptrace(PTRACE_DETACH).

pldd source:

if (ptrace (PTRACE_ATTACH, tid, NULL, NULL) != 0)
/* There might be a race between reading the directory and
threads terminating. Ignore errors attaching to unknown
threads unless this is the main thread. */
if (errno == ESRCH && tid != pid)

error (EXIT_FAILURE, errno, gettext ("cannot attach to process %lu"),

struct thread_list *newp = alloca (sizeof (*newp));
newp->tid = tid;
newp->next = thread_list;
thread_list = newp;

closedir (dir);

int status = get_process_info (dfd, pid);

assert (thread_list != NULL);
ptrace (PTRACE_DETACH, thread_list->tid, NULL, NULL);
thread_list = thread_list->next;
while (thread_list != NULL);

Seems this usually works only because cycles expended between attach and
detach is usually enough to let trap happen so tracee can set its state
to TASK_TRACED as PTRACE_DETACH expects it to be.

Is this expected behavior? It looks a bit like "Doctor Doctor..".


 \ /
  Last update: 2013-07-23 12:41    [W:0.072 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site