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?Received on Wed Jul 13 2016 - 01:58:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC