Date: Tue, 12 Jul 2016 20:51:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Johnston <markj@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: ptrace attach in multi-threaded processes Message-ID: <20160712175150.GP38613@kib.kiev.ua> In-Reply-To: <20160712170502.GA71220@wkstn-mjohnston.west.isilon.com> References: <20160712011938.GA51319@wkstn-mjohnston.west.isilon.com> <20160712055753.GI38613@kib.kiev.ua> <20160712170502.GA71220@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 before the attach. This means that it is not > possible to gcore a process without potentially leaving it stopped, for > instance. This result may occur in a single-threaded process > as well, since a signal may already be queued when the PT_ATTACH handler > sends SIGSTOP. I still miss somethine. Isn't this an expected outcome from sending a signal with STOP action ? > Indeed, I somehow missed that. I had assumed that the leaked TDB_XSIG > represented a bug in ptracestop(). It could, I did not made any statements that deny the bug: > > > Moreover, in my scenario I see a thread with TDB_XSIG set even after > > > ptrace(PT_DETACH) was called (P_TRACED is cleared). > > This is interesting, we indeed do not clear the flag consistently. > > But again, the only consequence seems to be a possible invalid reporting > > of events.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160712175150.GP38613>