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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"