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?
@koakuma have you tried running it non-single-step but one thread at a time? Iirc scheduler-locking is the keyword to look for and that will obviously require some manual action when the thread you are running starts to wait on some other thread (e.g. break on futex(FUTEX_WAIT) and then manually switch to some other thread that's not doing that)
@robryk With scheduler-locking set to on, I don't see any difference (crashes if breakpoint is not set)
@koakuma unless I totally forgot how scheduler-locking works this narrows down everything to one kind of race condition: where you need some other thread to take action early enough or the main thread dies. (Iirc doing what you've done means that only the main thread runs.)
