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

Dmitry Vyukov dvyukov at google.com
Wed Feb 18 10:14:19 PST 2015

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;
earthdok wrote:
> passing uptr* in place of int*
status has type 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);
earthdok wrote:
> indent
it is 4 spaces aligned
in accordance with the Style

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

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



More information about the llvm-commits mailing list