On 10/06, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 21:00:37 +0200, Oleg Nesterov wrote:
On 10/05, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX)
and then another/same tracer does
On Tue, 06 Oct 2009 15:10:10 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 21:00:37 +0200, Oleg Nesterov wrote:
On 10/05, Jan Kratochvil wrote:
Naive programs expect the first signal after PTRACE_ATTACH will be
SIGSTOP.
They should not, this
On 10/06, Jan Kratochvil wrote:
On Tue, 06 Oct 2009 15:10:10 +0200, Oleg Nesterov wrote:
Once again. Suppose that the tracer does ptrace(PTRACE_DETACH, SIGXXX).
Currently, if the next thacer attaches right after this detach it has no
way to intercept SIGXXX, it will be never reported via
On Tue, 06 Oct 2009 19:14:28 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
[...]
If it is not reported to the new tracer then it will be always
processed by the tracee, is it right?
Yes, sure.
(But, just in case... if the tracer does ptrace(DETACH, SIGNR), this
signr
On 10/06, Jan Kratochvil wrote:
On Tue, 06 Oct 2009 19:14:28 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
[...]
If it is not reported to the new tracer then it will be always
processed by the tracee, is it right?
Yes, sure.
(But, just in case... if the tracer
On Tue, 06 Oct 2009 22:05:16 +0200, Oleg Nesterov wrote:
For example, the tracee reports PTRACE_EVENT_EXEC and stops. In this
case SIGNR has no effect after PTRACE_CONT/DETACH/etc.
SIGNR does not ignored after the tracee reported syscall entry/exit or
signal.
OK, if only such exceptional
