Date: Mon, 10 May 2010 20:07:27 -0700 From: Ben Widawsky <widawsky@gmail.com> To: gljennjohn@googlemail.com Cc: freebsd-current@freebsd.org Subject: Re: PT_ATTACH resumes suspended process Message-ID: <AANLkTilPuhosrlpaK3LLYJeT0FujwtiLuzIcYbIQ_tTl@mail.gmail.com> In-Reply-To: <20100508135031.00fcd71e@ernst.jennejohn.org> References: <y2y121e074a1005071352re9572669of2c2a10f0e754ee3@mail.gmail.com> <20100508135031.00fcd71e@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clea= r > 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. =A0M= aybe > 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 =3D=3D 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 i= n kern_ptrace to handle PT_ATTACH when the process is suspended, the code wou= ld end up being almost identical to ptracestop(). Unless I didn't follow you. Because of this, I think what I suggested initially, esentially resuming th= e thread with a pending SIGSTOP (by checking the value of xsig when the threa= d switches back in issignal) would be a better approach. The hack I put in bo= thers me a bit because some of the other threads may resume, and even run for a w= hile, but it's still better than the existing behavior.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilPuhosrlpaK3LLYJeT0FujwtiLuzIcYbIQ_tTl>