Origin tracking is not async signal safe

[GoogleCodeExporter]

Chained origins make plain memory accessed async-signal-unsafe.
We disable this in signal handlers to avoid deadlock.
We need to take care of fork(), too, by either
- making stackdepot::Put() async-signal-safe
- acquiring all locks in the stackdepot pre-fork and releasing them post-fork
- disabling origin handling after fork in multi-threaded apps

The second options seems easiest.

Original issue reported on code.google.com by euge...@google.com on 3 Sep 2014 at 11:54

[GoogleCodeExporter]

Normal origins are also not fork-safe, because we wrap stack origins with one 
level of chained origin for uniformity. This may be a performance issue as 
well. We should stop doing that.

This wrapping has been causing a higher than expected collision rate in the 
chainedorigindepot, too.

Original comment by euge...@google.com on 3 Sep 2014 at 2:17

[GoogleCodeExporter]

http://llvm.org/viewvc/llvm-project?view=revision&revision=217140

Original comment by euge...@google.com on 4 Sep 2014 at 10:46

[GoogleCodeExporter]

What's left to fix here is __msan_set_alloca_origin4 going into chained origin 
depot. This is (a) inefficient and (b) async signal unsafe.

Original comment by euge...@google.com on 14 Oct 2014 at 9:05

• Changed title: Origin tracking is not async signal safe

[GoogleCodeExporter]

This has been fixed a while back in r223233.

Original comment by euge...@google.com on 21 Jan 2015 at 9:49

• Changed state: Fixed

[GoogleCodeExporter]

Adding Project:MemorySanitizer as part of GitHub migration.

Original comment by gli...@google.com on 30 Jul 2015 at 9:22

• Added labels: ProjectMemorySanitizer