[PATCH] tsan: fix PTRACE_ATTACH handling during stop-the-world

Sergey Matveev earthdok at google.com
Wed Feb 18 10:33:27 PST 2015


================
Comment at: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:114
@@ +113,3 @@
+    // continue to wait for stopping, because the thread is not stopped yet.
+    // We do ignore delivery of SIGSTOP, because we want to make stop-the-world
+    // as invisible as possible.
----------------
dvyukov wrote:
> earthdok wrote:
> > We do actually want to stop the threads, though.
> > 
> > I think you misunderstood this part:
> > 
> > > The usual practice is to reinject these signals until SIGSTOP is seen, then suppress SIGSTOP injection.
> > 
> > This is "usual practice" for when you want the threads to keep running.
> Why do you think that my code does not stop threads?
> Or what do you suggest? I don't understand.
nevermind, I was reading it wrong

================
Comment at: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:119
@@ +118,3 @@
+      uptr waitpid_status;
+      HANDLE_EINTR(waitpid_status, internal_waitpid(tid, &status, __WALL));
+      int wperrno;
----------------
dvyukov wrote:
> earthdok wrote:
> > passing uptr* in place of int*
> status has type int
oops

================
Comment at: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:125
@@ +124,3 @@
+        VReport(1, "Waiting on thread %d failed, detaching (errno %d).\n",
+            tid, wperrno);
+        internal_ptrace(PTRACE_DETACH, tid, NULL, NULL);
----------------
dvyukov wrote:
> earthdok wrote:
> > indent
> it is 4 spaces aligned
> in accordance with the Style
nope, that's only for those cases where even the first parameter is wrapped
otherwise you align to the first parameter

================
Comment at: lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:130
@@ +129,3 @@
+      if (WIFSTOPPED(status) && WSTOPSIG(status) != SIGSTOP) {
+        internal_ptrace(PTRACE_CONT, tid, 0, (void*)(uptr)WSTOPSIG(status));
+        continue;
----------------
dvyukov wrote:
> earthdok wrote:
> > How about this part:
> > 
> > > Signal-delivery-stop is observed by the tracer as waitpid(2) returning with WIFSTOPPED(status) true, with the signal returned by WSTOPSIG(status).  If the signal is SIGTRAP, this may be a different kind of ptrace-stop; see the "Syscall-stops" and "execve" sections below for details.  If WSTOPSIG(status) returns a stopping signal, this may be a group-stop; see below.
> > 
> > and
> > 
> > > The fact that signal injection requests may be ignored when restarting the tracee after ptrace stops that are not signal-delivery-stops is a cause of confusion among ptrace users.  One typical scenario is that the tracer observes group-stop, mistakes it for signal-delivery-stop, restarts the tracee with
> > >  ptrace(PTRACE_restart, pid, 0, stopsig)
> > > with the intention of injecting stopsig, but stopsig gets ignored and the tracee continues to run.
> And what is about this? Please be more concrete.
Nevermind

http://reviews.llvm.org/D7723

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list