Re: PT_ATTACH resumes suspended process



Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clear
what's happening - in your testing the process was already stopped so
the code sets td_xsig to SIGSTOP and wakes it up to send it the signal.

But td_xsig doesn't seem to be used anywhere to set pending signals.  Maybe
I missed the place where that happens.

The assumption seems to be that a process being traced will only be
stopped if the debugger is already attached and that any signals being
sent to it are coming from the debugger itself.

This assumption is wrong if the process being attached to was already
stopped.

It seems to me that checking for req == PT_ATTACH when the process is
already stopped and doing a break; in that case might be a solution.

Could you be more specific? It seems to me even if you had a special case in
kern_ptrace to handle PT_ATTACH when the process is suspended, the code would
end up being almost identical to ptracestop(). Unless I didn't follow you.

Because of this, I think what I suggested initially, esentially resuming the
thread with a pending SIGSTOP (by checking the value of xsig when the thread
switches back in issignal) would be a better approach. The hack I put in bothers
me a bit because some of the other threads may resume, and even run for a while,
but it's still better than the existing behavior.
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: process in STOP state
    ... Attaching gdb helps because debugger gets signal reports instead of ... The only question is why the process gets SIGSTOP at all. ... describing a problem with ptrace and signals, so you might want to give ...
    (freebsd-stable)
  • ptrace bugs and related problems
    ... i386 binaries on the x86-64 kernel, and some apply to a bit more. ... message (PTRACE_EVENT_VFORK_DONE) from being sent unless the ptrace ... A debugger can set or get the siginfo. ... it's no fun to mix waitpid with signals or select. ...
    (Linux-Kernel)
  • [PATCH] Close a race between exit1() and SIGSTOP
    ... We ran into a bug at work recently where processes were reporting an exit ... status from waitof WIFSIGNALEDwith WTERMSIGof SIGSTOP. ... My first attempt at a fix was to simply ignore all signals once P_WEXIT is ... pid_t pid; ...
    (freebsd-arch)
  • Re: [PATCH] Close a race between exit1() and SIGSTOP
    ... exit status from waitof WIFSIGNALEDwith WTERMSIGof SIGSTOP. ... I narrowed this down to a race in exit1(). ... My first attempt at a fix was to simply ignore all signals once ... pid_t pid; ...
    (freebsd-arch)
  • [PATCH] signal handling race condition causing reboot hangs
    ... But the "sighand" lock is dropped in several cases before the task's ... If a process running on another cpu posts a SIGCONT or SIGKILL just after ... has blocked all other signals will result in an unkillable process. ... running with kill(-1, SIGSTOP) and killcalls to temporarily ...
    (Linux-Kernel)