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

Question

I got this message when testing my app on simulator:

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

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

Using Xcode 6.4 & 7.2

Answer 1

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

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.

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.

Answer 2

It's Xcode "acting up". I also got it once and fixed it by running this in Terminal:

rm -rf ~/Library/Developer/Xcode/DerivedData/* ~/Library/Caches/com.apple.dt.Xcode/*

Basically clears Xcode caches and derived data which sometimes get corrupt. Hope it works for you.