[PATCH] StopTheWorld in sanitizer_common (first commit)

Sergey Matveev earthdok at google.com
Tue Mar 12 13:28:00 PDT 2013


  This implementation follows the approach currently used in gperftools, which seems to be working fine for them.

  > Too many ways for the app to block signals that can't be intercepted?

  Basically, yes. Considering that we would have to enforce a permissive signal mask in every thread, I think it would be more intrusive compared to this approach, and probably more complicated / less reliable.


================
Comment at: lib/sanitizer_common/sanitizer_stoptheworld_linux.cc:290
@@ +289,3 @@
+                          (char *)&a_local_variable - kReservedStackSize,
+                          CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED,
+                          &tracer_thread_argument, 0, 0, 0);
----------------
Reid Kleckner wrote:
> You could use CLONE_SETTLS to make sure you get a separate errno.
> 
> Also, consider that any of the calls below may trigger _dl_runtime_resolve in the loader, which will expect TLS to be sane.  This could be a big source of bugs.
> 
> We used to have test cases in DynamoRIO that used raw clone, and you have to be super careful when you do it.
I think it's easier to make sure we don't touch errno in the caller thread than to deal with an entirely bogus TLS in the cloned thread.

WRT _dl_runtime_resolve I think we should be safe, because we only call internal_prctl and internal_waitpid here, which are our own statically linked syscall wrappers.


http://llvm-reviews.chandlerc.com/D469



More information about the llvm-commits mailing list