> Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX) > and then another/same tracer does ptrace(ATTACH, tracee) > then SIGXXX will not be reported to the new tracer.
Correct. > Why? Should utrace-ptrace be 100% compatible here? I think it should, yes. There is a rationale for it that makes sense to me, and it is most certainly consistent, observable behavior on which existing applications could very well depend subtly, so regardless of "right" I think this one is well within 100% bug-compatibility territory. The rationale I see is that the debugger observed the signal, decided it wanted the tracee to experience the normal effects of the signal and be done with it after that. If it's a termination signal, the debugger really expects that the tracee can do nothing but die. (Given the tortured historic logic of the ptrace code paths, this applies only to signal stops and only when it either passes back the same signal number or at least another one that is not blocked.) Now replace "debugger" with "monitor" or (dismal) "security-checking syscall tracing product", or just shudder while trying not to imagine what all inane things ptrace might already be in use for. It could be important to someone out there e.g. that some other process of the tracee's UID cannot race in there and rescue it from dying. > I do not think there is a "real life" application that does > ATTACH + DETACH and relies on fact it must not see this sig. We can hope, but we cannot assume. There are always better ways to achieve the same true ends than the corner case examples like the one I gave, but that doesn't mean people haven't written the stupid ones in applications already shipped long ago and never to be rethought again (until we get the blame for breaking them in the new kernel). Thanks, Roland
