On Mon, 05 Oct 2009 04:32:08 +0200, Oleg Nesterov wrote: > On 10/01, Jan Kratochvil wrote: > > > > the ptrace-testsuite > > http://sourceware.org/systemtap/wiki/utrace/tests > > > > currently FAILs (also) on Fedora 12 kernel-2.6.31.1-48.fc12.x86_64 for: > > FAIL: detach-stopped > > FAIL: stopped-attach-transparency [...] > As for user-space, I don't really understand the second test-case, > this again means I don't understand the supposed behaviour.
The high level goal is described at its top. Users expect that if they run `gstack PID' or `gcore PID' the target PID will be absolutely in the same state as before gstack/gcore. That means it will keep both whether it was / was not stopped and also any possible existing / non-existing pending signal for a possible future waitpid() from its real (non-ptrace) parent PID. Another question whether technically what it does is right but this high level goal is hopefully valid. > Except, stopped-attach-transparency prints > > Excessive waiting SIGSTOP after the second attach/detach > > afaics the test-case is not right here. attach_detach() leaves the > traced threads in STOPPED state, why pid_notifying_sigstop() should > fail? [ Not replying this part, have not built a kernel with this patch now. ] > In this case, I don't understand why stopped-attach-transparency > "sends" SIGSTOP to every sub-thread. If the tracer wants to stop > the thread group after detach, it can do > > ptrace(PTRACE_DETACH, anythread, SIGSTOP); > for_each_other_thread(pid) > ptrace(PTRACE_DETACH, anythread, 0); > > or just > > kill(SIGSTOP); > for_each_thread(pid) > ptrace(PTRACE_DETACH, anythread, 0); OK, it this is the recommended way I can fix the testcase this way. The all-threads-being-sent-SIGSTOP way IIRC worked on linux-2.6.9 but I do not think this part of the compatibility must be kept. Thanks, Jan
