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

Annoyance

Are we supposed guess what your code is doing? Show the relevant parts responsible. – Trautman

Posting code is irrelevant due to the fact that I have no idea what a k packet is and what code it could be referencing with this message. It's not a crash - just this message I've never seen. – Annoyance

If the code is irrelevant then I'm guessing the message is too... – Trautman

same here. this message is displayed even the debug session is not yet started. – Footrest

My guess, is Apple silently forces us to use new xCode 7. Some crashes of xCode during debug have become frequent last month... Now this message. – Principium

I got another k packet message today. Didn't really look at it. I was trying to save data to a file path, something went wrong and thousands of objects got created. Got a memory warning and then some k packet message. Does anyone know what a k packet is? Is it some atavistic C ghost coming back to haunt contemporary coders? – Annoyance

I got that error, too. Is anyone else using a real device instead of a Simulator? I've never seen it before until today, and I was using a real device. I unplugged my device (I don't remember if the project was still running, or not). A while later, I found that error in my console. – Jellied

same message here.. The funny thing is my xcode-7 is also not calling a function. It is a simple function call. The debugger goes all the way to the function call points but never calls it and k packet error pops in console. It does not crash or anything.. the code moves on without calling the function. – Deprecatory

Got it again just now. Clicked run, and I guess it built on Simulator 5S but then I stopped it. Got the message when I stopped it. – Annoyance

I am also got the same error while running on the device. Don't know what to do. Any help plz... – Cyrillus

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.

Confute

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.

Peters

I'll try this if it happens again. Do you know what a k packet is? – Annoyance

@Annoyance Yes I'm eagering to know what's that too. – Vitkun