Messages in this thread | | | Date | Thu, 27 Jan 2011 18:48:57 +0100 | From | Tejun Heo <> | Subject | Re: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED |
| |
Hello,
On Thu, Jan 27, 2011 at 04:46:00PM +0100, Tejun Heo wrote: > On Mon, Jan 17, 2011 at 06:14:17PM -0800, Roland McGrath wrote: > > Oh, and for any kind of ptrace changes, please always run the whole > > ptrace-tests suite before and after. That is by no means an exhaustive > > test that you haven't introduced new problems. But if you introduce > > regressions in that suite, it is quite like that you are causing problems > > for existing ptrace users like gdb (even if some tests were racy before, > > if the real-world practical results change, it could be a problem). > > > > http://sourceware.org/systemtap/wiki/utrace/tests has the pointers. > > Alright, will try to do that.
Okay, just finished ran make check with and without the patchset. Without the patchset, 2.6.38-rc2 failed five tests. With the patchset six. The one extra test which failed was attach-sigcont-wait because the tracee now always enters TRACED after PTRACE_ATTACH, which I think is the correct behavior because the previous behavior where a stopped task honors SIGCONT unconditionally if it was delivered before the next ptrace call (any operation other than detach) doesn't make any sense to me in addition to the fact that it was buggy regarding the arch hook.
Is there an actual use case which requires this behavior? We can try to emulate the original behavior but I don't think it's a sane one.
Another difference was how stopped-detach-sleeping failed. It failed both with and without the patchset but with the patchset it triggered an assert(). The difference was because the assert() was testing whether the task was in STOPPED state after attach - it's now in TRACED state instead. With the assert removed, it failed the same way.
Thanks.
-- tejun
| |