[PATCH] D30818: [lsan] Don't handle DTLS of thread under destruction

[Maxim Ostapenko via Phabricator via llvm-commits]

m.ostapenko added a comment.

After more debugging it seems that the issue is even more complicated.

  Tracer caught signal 11: addr=0x7fb108da4000 pc=0x423990 sp=0x7fb135ffed90
  ==9109==Process memory map follows:
  	0x000000400000-0x000000441000	/tmp/a.out 0x000000000005
  	0x000000641000-0x000000642000	/tmp/a.out 0x000000000001
  	0x000000642000-0x000000645000	/tmp/a.out 0x000000000003
  ...
          0x7fb1085a4000-**0x7fb108da4000**	 rw (0x000000000003)

The faulty address looks fine (addressable and accessible), but the problem seems to be pretty similar to that we saw in fast unwinder some time ago (fixed by Evgeniy with https://reviews.llvm.org/rL219683).
Possible explanation (that we considered when debugging segfault in unwinder) looks like this:

1. Kernel maps stacks from higher addresses to lower (MAP_GROWSDOWN flag in mmap syscall).
2. Kernel maps stacks non-atomically (i.e not all ulilmit amount of stack memory become addressable simultaneously, lower pages become available a little bit later than higher).
3. If we make access to *stack_top (== stack_bot - ulimit) before kernel actually mapped all ulimit range, we'll have segfault.

It's hard to trigger the issue within just one process, I can reproduce the segfault only when running three test cases from https://github.com/google/sanitizers/issues/757 in parallel (thus slowing down the kernel, perhaps).
I'm trying to cook a testcase now, but I'm not sure I can reproduce the issue without running several test instances simultaneously (e.g. ./test & ./test & ./test). Is it acceptable to have such a test in compiler-rt testsuite?


Repository:
  rL LLVM

https://reviews.llvm.org/D30818