Q: ptrace_detach() && UTRACE_DETACH

Oleg Nesterov oleg at redhat.com
Thu Aug 6 00:57:35 UTC 2009


Still no code, only questions.

One particular problem with attach/detach is that ptrace_detach_task(sig)
doesn't really detach if sig != 0. Instead of UTRACE_DETACH we clear
engine->data and do UTRACE_INTERRUPT. The actual detach should be done by
ptrace_report_signal()->ptrace_resumed which returns UTRACE_DETACH if
engine->data == NULL.

If another ptracer comes in between, it reuses this engine and sets the
new value of ->data.

This creates a lot of problems, and I can't find any solution. And I feel
we will have more problems when we move more data into engine->data.
Questions:

1. Suddenly I realized, I do not really understand why ptrace_attach()
   tries to reuse the "almost detached" engine. Can't attach just fail
   in this case as if the task is still ptraced?

   ptrace_detach() always wakes up the tracee. This means it should call
   utrace_get_signal() soon and complete the detach.

   Yes, ptrace_detach()->wake_up_process() is actually wrong. This is not
   friendly if the tracee has other tracers. In fact it is wrong in any
   case if we want to respect SIGNAL_STOP_STOPPED like utrace_wakeup() does,
   but this was already discussed.

   But, until we change/fix this unconditinal wakeup, any other reason why
   the new debugger should try to re-use?

2. Or. Perhaps we can add ptrace_utrace_detached_ops ? All methods should
   return UTRACE_DETACH, except ptrace_utrace_detached_ops->report_signal()
   fixups ->last_siginfo and returns UTRACE_SIGNAL_XXX | UTRACE_DETACH.

   ptrace_detach_task() sets engine->ops = ptrace_utrace_detached_ops before
   utrace_control(UTRACE_INTERRUPT). We don't even need utrace_barrier().

   This means that the new debugger can another engine.

   Do you think this can work?

3. A bit off-topic question. I can't understand ptrace_detach(sig) with
   ptrace_report_syscall().

   Currently (without utrace), if we detach when the tracee sleeps after
   ptrace_report_syscall()->ptrace_notify(), we set ->exit_code = sig and
   the tracee send this sig to itself after wakeup.

   But, utrace-ptrace does this differently. report_syscall_xxx() do not
   play with signals, instead when ptracer does PTRACE_CONT/etc we send
   the signal to tracee before wakeup. (btw, send_sig() is wrong, the
   child can be dead without ->signal).

   This means that with utrace-ptrace ptrace_detach(sig) does not imply
   the signal if the tracee reported PTRACE_EVENT_SYSCALL.

   Should be fixed or I missed something?

Oleg.




More information about the utrace-devel mailing list