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
// for the async packet did cause the stop
if (continue_after_async)
{
- //continue_packet.assign (1, 'c');
+ // Reverting this for now as it is causing deadlocks
+ // in programs (<rdar://problem/11529853>). In the future
+ // we should check our thread list and "do the right thing"
+ // for new threads that show up while we stop and run async
+ // packets. Setting the packet to 'c' to continue all threads
+ // is the right thing to do 99.99% of the time because if a
+ // thread was single stepping, and we sent an interrupt, we
+ // will notice above that we didn't stop due to an interrupt
+ // but stopped due to stepping and we would _not_ continue.
+ continue_packet.assign (1, 'c');
continue;
}
}