Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race | Date | Tue, 9 Sep 2008 22:55:04 -0700 (PDT) |
| |
This subject line is quite far from what you're now addressing, btw.
I certainly wouldn't recommend that patch. The interference between ptrace uses of SIGTRAP and a program that blocks SIGTRAP is just a fact of life with ptrace. If you wanted to change the exec SIGTRAP to be more consistent with other signals induced by debuggers (such as breakpoints and single-step), you could just change send_sig to force_sig. That unblocks SIGTRAP and resets its handler when it's blocked. Conversely, a tracer program could use PTRACE_O_TRACEEXEC if it cared to deal with tracing a process that blocks SIGTRAP. (That uses ptrace_notify rather than any actual signal that can be blocked.)
But, none of this goes to your actual problem at all AFAICT. You've said your actual problem with strace only arises on ia64. The behavior of ptrace'd exec, and the effect of a program blocking SIGTRAP, is exactly the same across all machines. Changing it does not explain your situation. I'm in favor of understanding what is actually going on before changing things.
If the SIGTRAP from exec is actually seen by strace on a different machine like it's not on ia64, that suggests that something different happened between the two. In the case that doesn't exhibit the problem, either SIGTRAP got unblocked by something before the exec, or userland (strace) behaves differently so that it doesn't care about not seeing that SIGTRAP.
Thanks, Roland
| |