lkml.org 
[lkml]   [2011]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC] Proposal for ptrace improvements
    On Wed, Mar 2, 2011 at 3:43 PM, Tejun Heo <tj@kernel.org> wrote:
    >> # ./a.out
    >> PID: 16382
    >>  <------ kill -STOP 16382
    >>  <------ kill -ABRT 16382
    >>  <------ kill -WINCH 16382
    >>  <------ kill -CONT 16382
    >> sig: 28 Window changed
    >> sig: 18 Continued
    >> sig: 6 Aborted
    >> after sleep: errno=4 Interrupted system call
    >> PID: 16382
    >>
    >>
    >> Therefore we also need to think about this aspect of SIGCONT behavior
    >> under debuggers.
    >>
    >> Do we provide for the mechanism for debuggers to
    >> prevent execution of *SIGCONT userspace handler*?
    >
    > Yeah, it's not different from any other signal.  Just squash the
    > signal when ptrace signal delivery trap is taken, which is completely
    > separate from termination of job control stop triggered by _emission_
    > of SIGCONT.  The two are separate.  The proposed changes don't affect
    > the delivery path at all.  I really can't understand what your point
    > is.
    >
    >> And, looking at the example above, I see that on resume from stop,
    >> *SIGCONT userspace handler* actually doesn't run as *the first handler*
    >> after SIGCONT. Other pending signal's handlers may be executed before it.
    >
    > Signal delivery is not FIFO.  There are some rules that the code
    > describes.  If you're interested, take a look at the code but in
    > general it would be better to avoid assuming fixed order between
    > signal generations and deliveries.

    The above example does not show any FIFO-like behavior.

    What it does show is that signals queued during stop take effect
    immediately after job control stop is terminated.

    >> How would the above example look under ptraced process? Particularly,
    >> this sequence:
    >>  <------ kill -STOP 16382
    >>  <------ kill -ABRT 16382
    >>  <------ kill -WINCH 16382
    >>  <------ kill -CONT 16382
    >> sig: 28 Window changed
    >> sig: 18 Continued
    >> sig: 6 Aborted
    >
    > There's NO difference regarding signal delivery.  It stays the SAME.

    Ok, let's see whether I understand you.

    Assuming the program is run under simple debugger which
    resumes execution using PTRACE_CONT(sig) on signal delivery stops,
    with PTRACE_CONT(0) on ptrace stops,
    and doesn't do any PTRACE_CONT on job control stops,
    with your proposal the debugger will see and perform
    the following actions:

    waitpid...
    <------ kill -STOP 16382
    waitpid returns WSTOPPED, WSTOPSIG = SIGSTOP
    ptrace(PTRACE_GETSIGINFO) doesn't fail (=> it's signal delivery)
    ptrace(PTRACE_CONT, SIGSTOP)
    waitpid returns WSTOPPED, WSTOPSIG = SIGSTOP
    ptrace(PTRACE_GETSIGINFO) fails (=> it's job control stop)
    waitpid...
    <------ kill -ABRT 16382
    ...debugger doesn't wake up...
    <------ kill -WINCH 16382
    ...debugger doesn't wake up...
    <------ kill -CONT 16382
    waitpid returns WSTOPPED, WSTOPSIG = SIGTRAP (it's a ptrace-stop)
    ptrace(PTRACE_CONT, 0)
    waitpid returns WSTOPPED, WSTOPSIG = SIGWINCH
    ptrace(PTRACE_CONT, SIGWINCH)
    waitpid returns WSTOPPED, WSTOPSIG = SIGCONT
    ptrace(PTRACE_CONT, SIGCONT)
    waitpid returns WSTOPPED, WSTOPSIG = SIGABRT
    ptrace(PTRACE_CONT, SIGABRT)

    Correct?

    --
    vda
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-03-02 16:19    [W:2.305 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site