I'm replying out of order. So I'm sorry I started rehashing some of this
same stuff in the other thread before reading where you'd already referred
to it.
What if the tracee reports a signal and stops, the tracer detaches
but does not wake it up because of SIGNAL_STOP_STOPPED ? In this
case
I think always-reply-to-all is the best policy ;)
For some people's mail-handling habits it makes a difference, so it is
always safest not to trim individuals. For me personally, I always
see the list copies just the same as the ones CC'd to me personally,
so I don't care to be in the CC list
On Sat, 10 Oct 2009 18:24:21 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
Yes, I agree with the current general behavior of ptrace there is missing:
if (WIFSTOPPED (status) WSTOPSIG (status) == SIGPIPE)
[...snip...]
--- attach-into-signal.c31 Jan 2009
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:24:21 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
Yes, I agree with the current general behavior of ptrace there is missing:
if (WIFSTOPPED (status) WSTOPSIG (status) == SIGPIPE)
[...snip...]
On Sat, 10 Oct 2009 18:48:29 +0200, Oleg Nesterov wrote:
On 10/10, Jan Kratochvil wrote:
(VERBOSE-caught with FAIL now).
Cough. please translate this to me ;)
(Cc of each such mail to Roland does not look OK to me but removing Ccs is
also not OK)
--- tests/attach-into-signal.c 6 Oct 2009
On Wed, 07 Oct 2009 15:33:49 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
It should work also for PTRACE_SINGLESTEP.
Heh. Yes, but with one exception.
- the tracee has a hanlder for, say, SIGHUP
- the tracee deques SIGHUP, reports to the tracer,
and
On 10/07, Jan Kratochvil wrote:
OK, this is really a border case I did not mean.
In such case the SIGHUP handler still is not fully execting and as the
non-realtime signals do not nest (count) it is OK it gets activated only once.
I did mean some more normal case of:
ptrace
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
Naive programs expect the first signal after PTRACE_ATTACH will be SIGSTOP.
They should not, this is just wrong.
And I think the proposed change doesn't change the behaviour
in this sense.
It does not in the general sense. But it does change the behavior of
certain 100% predictable
OK. Let's see what Roland thinks.
I think the whole stoppedness vs detach et al discussion is a separate
issue from the basic PTRACE_DETACH,signr behavior, and I think I want to
discuss that in the other thread we have whose subject says it's about
that. I think I've covered the (separate)
In which specific cases SIGNR can get ignored?
There are two fundamental kinds of ptrace stops: real signal stops, and
fake (or ptrace_notify()) stops. In the latter, you are not in the
right place in the kernel for direct signal delivery, so it never works
fully normally. All the optional
after which the full range of
[oops, left that thought unfinished!]
... signal control options works (immediate delivery, SETSIGIFNO obeyed)
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 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
On 10/05, Oleg Nesterov wrote:
On 10/05, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
It is not trivial to implement, and I don't understand why
it is important to keep this behaviour. But we have the test
case which checks this:
Jan, Roland, I have the question.
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.
Why? Should utrace-ptrace be 100% compatible here?
It is not trivial to implement, and I
19 matches
Mail list logo
