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

[Sergey Matveev]

================
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.
----------------
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.

================
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;
----------------
passing uptr* in place of int*

================
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);
----------------
indent

================
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;
----------------
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.

================
Comment at: test/tsan/signal_segv_handler.cc:36
@@ -38,3 +35,3 @@
   }
  done:
   fprintf(stderr, "DONE\n");
----------------
don't need this anymore

http://reviews.llvm.org/D7723

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