如果你看一下文件进程GDBRemote.cpp http://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp在 llvm 源代码中，您将看到当 Xcode 的调试器进程出现意外响应时会发生这种情况，在这种情况下，如果数据包不是'W' or 'X'人物：
Error
ProcessGDBRemote::DoDestroy ()
{
// ...
if (m_gdb_comm.SendPacketAndWaitForResponse("k", 1, response, send_async) == GDBRemoteCommunication::PacketResult::Success)
{
char packet_cmd = response.GetChar(0);
if (packet_cmd == 'W' || packet_cmd == 'X')
{
// ...
}
else
{
if (log)
log->Printf ("ProcessGDBRemote::DoDestroy - got unexpected response to k packet: %s", response.GetStringRef().c_str());
exit_string.assign("got unexpected response to k packet: ");
exit_string.append(response.GetStringRef());
}
// ...
SetExitStatus(exit_status, exit_string.c_str());
StopAsyncThread ();
KillDebugserverProcess ();
return error;
}
在这种情况下，调试器正在发送字符串"OK"代替"W" or "X"。你无能为力，Xcode 幕后有问题。我发现在重新连接到调试会话之前终止 Xcode 的调试进程、重新启动 Xcode 以及重新启动计算机可以解决此问题。
要了解有关 OS X 上本机进程的更多信息，请查看该嵌套进程内的注释if陈述：
// For Native processes on Mac OS X, we launch through the Host Platform, then hand the process off
// to debugserver, which becomes the parent process through "PT_ATTACH". Then when we go to kill
// the process on Mac OS X we call ptrace(PT_KILL) to kill it, then we call waitpid which returns
// with no error and the correct status. But amusingly enough that doesn't seem to actually reap
// the process, but instead it is left around as a Zombie. Probably the kernel is in the process of
// switching ownership back to lldb which was the original parent, and gets confused in the handoff.
// Anyway, so call waitpid here to finally reap it.
关于为什么会发生此错误的有用评论：
// There is a bug in older iOS debugservers where they don't shut down the process
// they are debugging properly. If the process is sitting at a breakpoint or an exception,
// this can cause problems with restarting. So we check to see if any of our threads are stopped
// at a breakpoint, and if so we remove all the breakpoints, resume the process, and THEN
// destroy it again.
//
// Note, we don't have a good way to test the version of debugserver, but I happen to know that
// the set of all the iOS debugservers which don't support GetThreadSuffixSupported() and that of
// the debugservers with this bug are equal. There really should be a better way to test this!
//
// We also use m_destroy_tried_resuming to make sure we only do this once, if we resume and then halt and
// get called here to destroy again and we're still at a breakpoint or exception, then we should
// just do the straight-forward kill.
//
// And of course, if we weren't able to stop the process by the time we get here, it isn't
// necessary (or helpful) to do any of this.
