I've been working for a while on several bugs that are regressions of ptrace behavior in the latest utrace branch code. These are all now represented in the ptrace-tests suite; Denys Vlasenko <[EMAIL PROTECTED]> has been investigating the problems and adding test cases. (Thanks, Denys!) (http://sourceware.org/systemtap/wiki/utrace/tests)
The current Fedora 9 and 10 kernels have the code that was current in my GIT tree and people.redhat.com patches before today. That code exhibits several of these bugs. I've fixed a bunch of problems but am still fighting with some loose ends. Since I've been at it for quite a while, I've decided to commit the newer code today even though some problems remain. The current GIT branch and matching patches at http://people.redhat.com/roland/utrace/2.6-current/ have my latest code now (vs v2.6.28-rc6ish). I'm hoping some more eyeballs on the code might help me tie down some of the issues I'm still having. (I'm not updating the Fedora kernels with a new utrace patch yet.) There are two things I'm currently struggling with. 1. Intermittent failure of attach-into-signal. The failure mode has changed from the original one, and I haven't figured out what it's doing yet. 2. Among the "make xcheck" tests, late-ptrace-may-attach-check causes the the WARN_ON in ptrace_resumed() (kernel/ptrace.c:522) to hit. This might be ok to ignore, but I cannot figure out how it happens and I don't like being confused! If it can happen, then I'm worried that there may be a problem with the assumptions made about implicitly storing the old siginfo_t when ptrace stops. I think the WARN_ON should not be happening so I want to grok how it does. I was going to say, "All 'make check' tests pass except ..." before mentioning those two. But now it appears I've just introduced regressions into block-step and step-jump-cont* too. So those might need figured out. If anyone has any insight into any of these problems, or questions about what I've recently done in the code, please pipe up! Thanks, Roland
