Date: Tue, 12 Jul 2016 21:02:10 -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: <20160713040210.GA89573@wkstn-mjohnston.west.isilon.com> In-Reply-To: <20160713033036.GR38613@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, 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 ? > > > > It is. But I also expect a PT_DETACH operation to resume a stopped > > process, assuming that a second SIGSTOP was not posted while the > > process was suspended. > But as far as the situation was discussed, it seems that real SIGSTOP raced > with PT_ATTACH. And the offered interpretation that SIGSTOP was delivered > 'a bit later' than PT_ATTACH would fit into the description. 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. For instance, SIGHUP after a log rotation. If a real SIGSTOP races with PT_ATTACH, then I would indeed expect to find the process in a stopped state after the detach. Does this make more sense?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160713040210.GA89573>