Hendrik Greving

On TLB-threads: https://ci.appveyor.com/project/DynamoRIO/dynamorio/builds/25566147

On tool.drcachesim.coherence: https://ci.appveyor.com/project/DynamoRIO/dynamorio/builds/27243222

Happened again: https://ci.appveyor.com/project/DynamoRIO/dynamorio/builds/28271317?fullLog=true

Again: https://ci.appveyor.com/project/DynamoRIO/dynamorio/builds/29059846

I could reproduce this error occurring in about 1:1000 magnitude (or less): 283: Test command: /usr/local/google/home/hgreving/dynamorio/build/bin64/runstats "-s" "90" "-killpg" "-silent" "-env" "LD_LIBRARY_PATH" "/usr/local/google/home/hgreving/dynamorio/build/lib64/debug:/usr/local/google/home/hgreving/dynamorio/build/ext/lib64/debug:" "-env" "DYNAMORIO_OPTIONS" "-stderr_mask 0xC -dumpcore_mask 0 -code_api"...

I can reproduce timeout in about 1:10000. Looks like hang on attach, similar to xref #2601 . The thread in the wait loop never leaves the wait loop because supposedly...

Issue is that a thread in its late exit stage acquires the dynamo_vm_areas_lock when freeing its dstack (stack_free -> .. -> release_memory_and_update_areas). There is a small window in write_lock and...

Our observation is that in this test, a thread's exit had already started before detach started. During a following attach, the synchronization code A) either has a bug or B)...

The synchronization/barrier at detach was inspected and it turns out that it is currently is implemented to (supposed to-) actually wait for exiting threads. Adding assertions of exiting_thread_count == 0...

> I'm confused: if the thread exited how is it still in /proc? Hasn't exited, it's on its way to exit, I think it's a thread that's at the exit...