The ARM debug stub doesn't implement the critically important single (instruction) step functionality. When instructed to single step, it just continues the thread. When the debug stub believes it is in single step mode, it holds a lock on the threads table. When creating a thread, locking the threads table is also required. So if a thread tries to create a thread after being continued by the debugger, a deadlock results. This often happens for me when running run_break_continue_thread_test on an emulator VM. (The test always fails, but it might or might not hit the deadlock depending how the race condition plays out.)
I think the deadlock might be possible on x86 architectures too, via stepi into the create thread syscall. But the user can easily avoid it by not doing that :)
The ARM debug stub doesn't implement the critically important single (instruction) step functionality. When instructed to single step, it just continues the thread. When the debug stub believes it is in single step mode, it holds a lock on the threads table. When creating a thread, locking the threads table is also required. So if a thread tries to create a thread after being continued by the debugger, a deadlock results. This often happens for me when running
run_break_continue_thread_teston an emulator VM. (The test always fails, but it might or might not hit the deadlock depending how the race condition plays out.)I think the deadlock might be possible on x86 architectures too, via
stepiinto the create thread syscall. But the user can easily avoid it by not doing that :)