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.Received on Tue Jul 12 2016 - 15:51:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC