<rdar://problem/11529853>
authorGreg Clayton <gclayton@apple.com>
Thu, 24 May 2012 23:42:14 +0000 (23:42 +0000)
committerGreg Clayton <gclayton@apple.com>
Thu, 24 May 2012 23:42:14 +0000 (23:42 +0000)
commitf1186de3f4c7be6eee4690f365c79c69015a9096
treeacfb7d28bfe93e5eee2065d2894cdff42b1500c7
parent85d8f0cba8f763a90617293c46d423376d72b370
<rdar://problem/11529853>

Sending async packets can deadlock a program on darwin. We currently allow breakpoint packets and memory read/write packets (for software breakpoints) to be sent while a program is running. In the GDB remote plug-in, we will interrupt the run, send the async packet and resume (currently with the continue packet that caused the program to resume). If the GDB server supports the "vCont" packet, we might have initially continued with each thread stating it should continue. If new threads show up while we are stopped, which happend when running GCD, we can end up with new threads that we aren't mentioning in the continue list. So we start with a thread list of 1,2,3 and continue:

continue thread 1, continue thread 2, continue thread 3

Now we interrupt and set a breakpoint and we actually have threads 1,2,3,4 now when we are about to resume, yet we send:

continue thread 1, continue thread 2, continue thread 3

Any thread that isn't mentioned is currently going to stay suspended. This causes the deadlock.

llvm-svn: 157439
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp