[lkml]   [2011]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED
    On Fri, 24 Dec 2010 15:00:50 +0100, Tejun Heo wrote:
    > 1. When attaching to a STOPPED task or a traced task stops for group
    > stop, the tracee now enters TRACED instead of STOPPED. This is
    > visible via fs/proc but, more importantly, SIGCONT is ignored if a
    > task is TRACED.
    > The behavior before the change was quite erratic. The first ptrace
    > operation after the tracee enters STOPPED would silently transit
    > its state to TRACED behind its back bypassing arch_ptrace_stop().
    > This means that SIGCONT is honored until the first following ptrace
    > operation but ignored after that.
    > This may, for example, affect the operation of strace but given how
    > strace always need to issue further ptrace operations on trap to
    > determine what's going on, I doubt it would actually be worse.

    FSF GDB for `T (stopped)' processes currently does:
    check /proc/%d/status for `T (stopped)' (by GDB's pid_is_stopped)
    if found then kill (PID, SIGSTOP) && ptrace (PTRACE_CONT, PID, 0, 0).
    waitpid (pid, &status, 0) - so that this one does not get stuck if the stop
    event was already eaten out before.

    If the `T (stopped)' will now always FAIL then at leat the waitpid then should
    never get stuck.

    > 2. The transition between STOPPED and TRACED involves a short window
    > of RUNNING inbetween. On attach, the transition is hidden from the
    > tracer using GROUP_STOP_TRAPPING but it still is visible to other
    > threads in the tracer's group. IOW, if another thread performs
    > WNOHANG wait(2) on the tracee while attach is in progress, the
    > wait(2) may fail even if the tracee is known to be in stopped state
    > before.
    > The same problem exists the other direction during detach.
    > Currently, the code doesn't try to hide this transition even from
    > the tracer. IOW, if the tracer attaches to a stopped task,
    > detaches, reattaches and then performs WNOHANG wait(2), the wait(2)
    > may fail. However, given the previous behavior where the tracee is
    > always woken up by wake_up_process() on detach, this is highly
    > unlikely to cause any problem.

    FSF gdbserver --multi does PTRACE_ATTACH followed by waitpid (WNOHANG) and it
    fails if it returns ECHILD on the first try.

    ptrace(PTRACE_ATTACH, 22049, 0, 0) = 0
    wait4(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WNOHANG, NULL) = 22049

    It may be also a gdbserver bug, though.


     \ /
      Last update: 2011-01-12 22:47    [W:0.022 / U:3.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site