Date: Wed, 13 Jul 2016 13:01:39 -0700 From: Mark Johnston <markj@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current@FreeBSD.org Subject: Re: ptrace attach in multi-threaded processes Message-ID: <20160713200139.GC2066@wkstn-mjohnston.west.isilon.com> In-Reply-To: <20160713191947.GW38613@kib.kiev.ua> References: <20160712011938.GA51319@wkstn-mjohnston.west.isilon.com> <20160712055753.GI38613@kib.kiev.ua> <20160712170502.GA71220@wkstn-mjohnston.west.isilon.com> <20160712175150.GP38613@kib.kiev.ua> <20160712182414.GC71220@wkstn-mjohnston.west.isilon.com> <20160713033036.GR38613@kib.kiev.ua> <20160713040210.GA89573@wkstn-mjohnston.west.isilon.com> <20160713045439.GT38613@kib.kiev.ua> <20160713164247.GA2066@wkstn-mjohnston.west.isilon.com> <20160713191947.GW38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 handling is in stopevent(), since a thread calling stopevent() > > from postsig() may clear p_xthread after it was set by another thread in > > ptracestop(). But I also don't understand why we call stopevent(S_SIG) > > from both issignal() and postsig() - this would appear to stop the > > thread twice for the same signal. > You mean that the patch would not fix your issue ? Quite possible, it > might require some more code to 'move the torch' to next xthread, so to > say. When you write the test case, I will spend efforts on the working > patch. I don't think this addresses my issue of the process remaining stopped after the PT_DETACH, but see below. > > That said, I do not think that we should change anything about stopevent(), > since this is code which is on life support. If we cannot remove procfs > debugging interface, let not change it at least in incompatible ways. > > > > > With respect to the desired direction, do you agree that the SIGSTOP > > from PT_ATTACH should effectively be ignored if a different signal stops > > the process first? As I said in a previous post, it seems that the > > SA_STOP property of PT_ATTACH's SIGSTOP is not used in the common case, > > since ptracestop() will stop the process if any signal is received, and > > the PT_DETACH operation will typically overwrite the SIGSTOP with 0 in > > td_xsig. > Hmm, I think no, we can not make such change. Issue is, debugger > interface guarantees (at least for single-threaded programs it is > done correctly) that SIGSTOP is noted. In my opinion, it would be the > incompatible API change. But this guarantee is not honoured in the single-threaded case where PT_ATTACH sends SIGSTOP after another signal is already pending. This other signal will stop the process in ptracestop(), so SIGSTOP will not be reported until after a PT_CONTINUE or PT_DETACH, which seems to violate the interface as you described it. Am I missing some reason that this cannot occur? If not, I'll write a test case for the single-threaded case first.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160713200139.GC2066>