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

Reply via email to