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 https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"