CRASH (CL #102150043) Thread appears to escape after FLS deadlock

_From [byron.c....@gmail.com](https://code.google.com/u/101184679827294438523/) on June 05, 2014 18:29:27_

To reproduce:
1. Build CL `#102150043` in Windows x64
2. Run the test "client.annotation" by launching it in windbg
3. Execute the following commands in windbg:

.childdbg 1
g
l+t
l+s
!sym noisy
.lines
sxi 80000003
sxd av
g

If ntdll is loaded here:

```
00000000`77780000 00000000`77929000 ntdll
```

Then there should be an AV in ntdll like this:

```
00000000`77787142 48894a10 mov qword ptr [rdx+10h],rcx ds:00000000`bf1c8cc9=58247c8348eb3024
```

Or like this:

```
00000000`77787143 894a10 mov dword ptr [rdx+10h],ecx ds:00000000`bf1c8cc9=48eb3024
```

The call stack for the main thread looks like:

```
0xbf2c3fa3
KERNELBASE!WaitForMultipleObjectsEx+0xe8
kernel32!WaitForMultipleObjects+0xb0
client_annotation!main+0x723
client_annotation!__tmainCRTStartup+0x144
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1
```

The crashed thread appears to have escaped DR control:

```
ntdll!RtlpWakeSRWLock+0xb6
ntdll!RtlProcessFlsData+0x169
KERNELBASE!FlsSetValue+0x5d
client_annotation!_threadstartex+0x37
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d
```

Other threads are normal:

```
ntdll!NtWaitForSingleObject+0xa
dynamorio!nt_wait_event_with_timeout+0x20
dynamorio!os_wait_event+0x194
dynamorio!mutex_lock+0xfe
dynamorio!acquire_recursive_lock+0x43
dynamorio!loader_thread_exit+0x34
dynamorio!dynamo_thread_exit_common+0x4fb
dynamorio!dynamo_thread_exit+0x26
dynamorio!cleanup_and_terminate+0x8b
0x7ff`fffd8000
dynamorio!cleanup_and_terminate+0x60
0xbf3590c0

ntdll!ZwWaitForKeyedEvent+0xa
ntdll!RtlAcquireSRWLockExclusive+0x106
ntdll!RtlProcessFlsData+0x144
KERNELBASE_220000!FlsSetValue+0x5d
client_annotation_dll!__crtFlsSetValue+0x45
client_annotation_dll!_CRT_INIT+0x197
client_annotation_dll!__DllMainCRTStartup+0x7b
client_annotation_dll!_DllMainCRTStartup+0x31
dynamorio!privload_call_entry+0x434
dynamorio!loader_thread_init+0xf4
dynamorio!dynamo_thread_init+0x9e8
dynamorio!intercept_new_thread+0x170
dynamorio!intercept_ldr_init+0x86
dynamorio!interception_code_array+0x8dc
0x1b0f7b8

ntdll!NtWaitForSingleObject+0xa
dynamorio!nt_wait_event_with_timeout+0x20
dynamorio!os_wait_event+0x194
dynamorio!mutex_lock+0xfe
dynamorio!acquire_recursive_lock+0x43
dynamorio!loader_thread_init+0xae
dynamorio!dynamo_thread_init+0x9e8
dynamorio!intercept_new_thread+0x170
dynamorio!intercept_ldr_init+0x86
dynamorio!interception_code_array+0x8dc
0x1c9f3f8
```

The crashed thread did get hooked at LdrInitializeThunk(), and it entered the code cache in a normal way (ad hoc logging):

Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000173f948
New thread enters fcache at 0x00000000bff4e1e0: RSP=0x000000000019fde0
Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000163f308
New thread enters fcache at 0x00000000bfdc4000: RSP=0x000000000019f8c8
New thread enters fcache at 0x00000000bff4e213: RSP=0x000000000163f308
New thread enters fcache at 0x00000000bff4e458: RSP=0x000000000173f8b0
Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000195f3d8
New thread enters fcache at 0x00000000bff4e213: RSP=0x000000000195f3d8
New thread enters fcache at 0x00000000bff4e0d8: RSP=0x000000000019f8c8
Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000184f7c8
New thread enters fcache at 0x00000000bff4e213: RSP=0x000000000184f7c8
New thread enters fcache at 0x00000000bff4e4f0: RSP=0x000000000019fe30
New thread enters fcache at 0x00000000bff4e4b0: RSP=0x000000000173f8a8
Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000168f608 > crashed thread
New thread enters fcache at 0x00000000bff4e213: RSP=0x000000000168f608
New thread enters fcache at 0x00000000bff4d620: RSP=0x000000000019f8d0
Takeover thread. Start pc 0x0000000015565944. RSP 0x000000000181f388
Takeover thread. Start pc 0x0000000015565944. RSP 0x0000000001a3f3b8
New thread enters fcache at 0x00000000c0092178: RSP=0x000000000181f770
New thread enters fcache at 0x00000000bff4e213: RSP=0x0000000001a3f3b8
New thread enters fcache at 0x00000000bfdda576: RSP=0x000000000181eee0

xref issue #875 where the call stacks look very similar, but the thread in RtlpWakeSRWLock() gets stuck instead of proceeding and crashing.

Note that this issue is avoided by building the test target without libc.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1455_