[PATCH] D45646: [tsan] Zero out the shadow memory for the stack and TLS in ThreadFinish

[Kuba (Brecka) Mracek via Phabricator via llvm-commits]

kubamracek added a comment.

Okay. I can reproduce the same crash with pthreads and mmap'ing/munmap'ing memory at the region where threads' stacks are usually created. However, this is a slightly different problem from what I'm trying to solve here. There's two variations of this:

1. User code uses memory that will later be re-used as a thread's stack. This can be handled with interceptors (we can catch mmap and munmap).
2. The kernel spawns and destroys wq threads (which happens spontaneously, without the process direct control). We get notifications about these events via `my_pthread_introspection_hook` in `tsan_platform_mac.cc`. (As a side note, we also have to work with the fact the thread creation event is not sent "soon enough", i.e. many interceptors get called before we receive the event, and the thread destruction event is not sent "late enough", i.e. interceptors get called after that event.)

I can reproduce both the issues (however the reproducer for the second one is not suitable to be a lit test, as it takes 30-60 seconds to trigger). I'm not too worried about the first variation. It's very unlikely that user code will try to `mmap(MAP_FIXED)` into the area of thread stacks, and non-fixed mmap will avoid this area. Mostly I'm worried about the situation where one thread doesn't clean up and a new thread will get its stack allocated over a previous thread.

Is moving the backing store of our "fake TLS" to the metamap going to help? I would need to add clearing of the metamap into ThreadFinish. Is that any better from clearing the normal shadow memory of the stack?

> Shadow memory is not guaranteed to be zeros for new memory.

Doesn't that cause some problems already?


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D45646