[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