ios - Xcode "Mensaje del depurador: obtuve una respuesta inesperada al paquete k: OK"

llvm xcode6.4

Question

Recibí este mensaje al probar mi aplicación en el simulador:

Mensaje del depurador: obtuve una respuesta inesperada al paquete k: OK

¿Qué significa y mi aplicación está en algún tipo de peligro?

Usando Xcode 6.4 y 7.2

Answer 1

Es Xcode "actuando". También lo obtuve una vez y lo arreglé ejecutando esto en la Terminal:

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

Básicamente borra los cachés de Xcode y los datos derivados que a veces se corrompen. Espero que funcione para ti.

Answer 2

Si observa el archivo ProcessGDBRemote.cpp en el código fuente de llvm, verá que esto ocurre cuando hay una respuesta inesperada del proceso del depurador de Xcode, en este caso si el paquete no tiene los caracteres ''W'' o ''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;
}

En este caso, el depurador está enviando la cadena "OK" lugar de "W" o "X" . No hay nada que puedas hacer, hay un problema entre bastidores en Xcode. Descubrí que una solución para eliminar los procesos de depuración de Xcode, reiniciar Xcode y reiniciar su máquina antes de reconectarse a una sesión de depuración puede solucionar este problema.

Para obtener más información sobre los procesos nativos en OS X, consulte el comentario dentro de esa declaración anidada 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.

Comentarios útiles sobre por qué este error puede ocurrir:

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