Date: Sat, 8 May 2010 13:50:31 +0200 From: Gary Jennejohn <gljennjohn@googlemail.com> To: Ben Widawsky <widawsky@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: PT_ATTACH resumes suspended process Message-ID: <20100508135031.00fcd71e@ernst.jennejohn.org> In-Reply-To: <y2y121e074a1005071352re9572669of2c2a10f0e754ee3@mail.gmail.com> References: <y2y121e074a1005071352re9572669of2c2a10f0e754ee3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 May 2010 13:52:15 -0700 Ben Widawsky <widawsky@gmail.com> wrote: > If a debugger attaches to a suspended process, the process will be > resumed, and backgrounded. This seems like the incorrect behavior to me > based what I read in the man page. "The tracing process will see the > newly-traced process stop and may then control it as if it had been > traced all along." > > The behavior exhibited in FreeBSD is that the process is resumed, and we > will not reach ptracestop() until the next debugger command comes in. > [snip] 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. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100508135031.00fcd71e>