Xcode“来自调试器的消息：对k包有意外响应：OK” [英] Xcode "Message from debugger: got unexpected response to k packet: OK"

问题描述

我在模拟器上测试我的应用时收到此消息：

I got this message when testing my app on simulator:

来自调试器的消息：得到了对k数据包的意外响应：确定

Message from debugger: got unexpected response to k packet: OK

这是什么意思，我的应用程序是否有任何危险？

What does it mean and is my app in any sort of danger?

使用Xcode 6.4& 7.2

Using Xcode 6.4 & 7.2

推荐答案

如果查看文件 ProcessGDBRemote.cpp ，您会看到当出现意外响应时会发生这种情况来自Xcode的调试程序进程，在这种情况下，如果数据包不是'W'或'X'字符：

If you look at the file ProcessGDBRemote.cpp in the llvm source code, you will see that this occurs when there is an unexpected response from Xcode's debugger process, in this case if the packet is not the 'W' or 'X' characters:

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;
}

在这种情况下，调试器发送字符串确定而不是W或X。你无能为力，Xcode背后有一个问题。我发现在重新连接到调试会话之前杀死Xcode的调试进程，重新启动Xcode以及重新启动计算机的组合可以解决这个问题。

In this case the debugger is sending the string "OK" instead of "W" or "X". There's nothing you can do, there's a problem behind the scenes in Xcode. I've found that a combination of killing Xcode's debugging processes, restarting Xcode, and restarting your machine before reconnecting to a debugging session can fix this issue.

要了解更多信息，请访问： OS X上的本机进程，检查嵌套中的注释if 语句：

To learn more about native processes on OS X, checkout the comment inside of that nested if statement:

// 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.

有关可能出现此错误的有用评论：

Helpful comments on why this error might occur:

// 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.

这篇关于Xcode“来自调试器的消息：对k包有意外响应：OK”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！