Re: ptrace attach in multi-threaded processes

2016-07-16 Thread Konstantin Belousov
On Fri, Jul 15, 2016 at 11:01:59AM -0700, Mark Johnston wrote: > Thanks, this seems to give the desired behaviour in the single-threaded > case. I'll write a test case for the multi-threaded case next. > > Am I correct in thinking that r302179 could be reverted if your change > is committed? I sus

Re: ptrace attach in multi-threaded processes

2016-07-15 Thread Mark Johnston
On Fri, Jul 15, 2016 at 10:27:20AM +0300, Konstantin Belousov wrote: > On Thu, Jul 14, 2016 at 11:16:05AM -0700, Mark Johnston wrote: > > Please see the program here: > > https://people.freebsd.org/~markj/ptrace_stop.c > > > > It cheats a bit: it uses SIGSTOP to stop the child before sending a > >

Re: ptrace attach in multi-threaded processes

2016-07-15 Thread Konstantin Belousov
On Thu, Jul 14, 2016 at 11:16:05AM -0700, Mark Johnston wrote: > Please see the program here: > https://people.freebsd.org/~markj/ptrace_stop.c > > It cheats a bit: it uses SIGSTOP to stop the child before sending a > SIGHUP to it. However, this is just for convenience; note that PT_ATTACH > will

Re: ptrace attach in multi-threaded processes

2016-07-14 Thread Mark Johnston
On Thu, Jul 14, 2016 at 08:25:37AM +0300, Konstantin Belousov wrote: > On Wed, Jul 13, 2016 at 01:01:39PM -0700, Mark Johnston wrote: > > On Wed, Jul 13, 2016 at 10:19:47PM +0300, Konstantin Belousov wrote: > > > Hmm, I think no, we can not make such change. Issue is, debugger > > > interface guara

Re: ptrace attach in multi-threaded processes

2016-07-13 Thread Konstantin Belousov
On Wed, Jul 13, 2016 at 01:01:39PM -0700, Mark Johnston wrote: > On Wed, Jul 13, 2016 at 10:19:47PM +0300, Konstantin Belousov wrote: > > On Wed, Jul 13, 2016 at 09:42:47AM -0700, Mark Johnston wrote: > > > I'm having trouble determining if the diff changes any userland-visible > > > behaviour. It

Re: ptrace attach in multi-threaded processes

2016-07-13 Thread Mark Johnston
On Wed, Jul 13, 2016 at 10:19:47PM +0300, Konstantin Belousov wrote: > On Wed, Jul 13, 2016 at 09:42:47AM -0700, Mark Johnston wrote: > > I'm having trouble determining if the diff changes any userland-visible > > behaviour. It seems that the only potential problem with the current > > p_xthread ha

Re: ptrace attach in multi-threaded processes

2016-07-13 Thread Konstantin Belousov
On Wed, Jul 13, 2016 at 09:42:47AM -0700, Mark Johnston wrote: > On Wed, Jul 13, 2016 at 07:54:39AM +0300, Konstantin Belousov wrote: > > I finally see. Might be something like the patch below is a step in > > the desired direction. Idea is in the proc_next_xthread(): p_xthread > > should be set

Re: ptrace attach in multi-threaded processes

2016-07-13 Thread Mark Johnston
On Wed, Jul 13, 2016 at 07:54:39AM +0300, Konstantin Belousov wrote: > I finally see. Might be something like the patch below is a step in > the desired direction. Idea is in the proc_next_xthread(): p_xthread > should be set to the next thread with a pending signal. Do you have a > test case th

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Konstantin Belousov
On Tue, Jul 12, 2016 at 09:02:10PM -0700, Mark Johnston wrote: > Hm, the only SIGSTOP in my scenario is the one generated by PT_ATTACH. > The problem occurs when this SIGSTOP races with *any* other signal that's > being delivered to the process and for which the process has registered > a handler.

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Mark Johnston
On Wed, Jul 13, 2016 at 06:30:36AM +0300, Konstantin Belousov wrote: > On Tue, Jul 12, 2016 at 11:24:14AM -0700, Mark Johnston wrote: > > On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote: > > > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote: > > > > On Tue, Jul 12,

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Konstantin Belousov
On Tue, Jul 12, 2016 at 11:24:14AM -0700, Mark Johnston wrote: > On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote: > > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote: > > > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote: > > > I suppose it is n

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Mark Johnston
On Tue, Jul 12, 2016 at 08:51:50PM +0300, Konstantin Belousov wrote: > On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote: > > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote: > > I suppose it is not strictly incorrect. I find it surprising that a > > PT_ATTACH follow

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Konstantin Belousov
On Tue, Jul 12, 2016 at 10:05:02AM -0700, Mark Johnston wrote: > On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote: > I suppose it is not strictly incorrect. I find it surprising that a > PT_ATTACH followed by a PT_DETACH may leave the process in a different > state than it was in

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Mark Johnston
On Tue, Jul 12, 2016 at 08:57:53AM +0300, Konstantin Belousov wrote: > On Mon, Jul 11, 2016 at 06:19:38PM -0700, Mark Johnston wrote: > > Hi, > > > > It seems to be possible for ptrace(PT_ATTACH) to race with the delivery > > of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and > >

Re: ptrace attach in multi-threaded processes

2016-07-12 Thread Konstantin Belousov
On Mon, Jul 11, 2016 at 06:19:38PM -0700, Mark Johnston wrote: > Hi, > > It seems to be possible for ptrace(PT_ATTACH) to race with the delivery > of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and > sends SIGSTOP to a thread in the target process. Consider the case where > a sig

ptrace attach in multi-threaded processes

2016-07-11 Thread Mark Johnston
Hi, It seems to be possible for ptrace(PT_ATTACH) to race with the delivery of a signal to the same process. ptrace(PT_ATTACH) sets P_TRACED and sends SIGSTOP to a thread in the target process. Consider the case where a signal is delivered to a second thread, and both threads are executing ast() c