Don't you love it when clang test suite fails because of pthread_create bad address or something and the stack trace points to glibc

So it's like is clang breaking (scary) or it's glibc (scarier)

Though it only happens with clang-built-clang (and not with gcc-built-clang) so my guess is that it's clang that is broken but

Okay it seems to not happen when I set LIBCLANG_NOTHREADS so probably something happens during thread creation

Also, if I single-step through it with gdb then the problem's gone...

But it still happens if I just press continue through all the breakpoints

So, race condition?

So setting a breakpoint *just* before the instruction that traps to the kernel to do clone(2) seems to slow things down enough that the testcase succeeds, so now I strongly believe that this is indeed a race

Now the question is, how do I track this down

@koakuma is it simple to compile clang with clang with tsan or asan? (TSAN might not find a race condition that's not a data race, but if the symptom is unallocated memory deref, then asan's stacks at deallocation time might contain enough of a clue)