Я получил это сообщение при тестировании своего приложения на симуляторе:
Сообщение от отладчика: получен неожиданный ответ на k-пакет: OK
Что это значит и мое приложение в какой-то опасности?
Использование Xcode 6.4 и 7.2
Я получил это сообщение при тестировании своего приложения на симуляторе:
Сообщение от отладчика: получен неожиданный ответ на k-пакет: OK
Что это значит и мое приложение в какой-то опасности?
Использование Xcode 6.4 и 7.2
Если вы посмотрите на файл ProcessGDBRemote.cpp в исходном коде llvm, вы увидите, что это происходит, когда есть неожиданный ответ от Отладчик Xcode, в этом случае, если пакет не является символами 'W'
или '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"
или "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.
Это Xcode "действует". Я также получил его один раз и исправил его, выполнив это в терминале:
rm -rf ~/Library/Developer/Xcode/DerivedData/* ~/Library/Caches/com.apple.dt.Xcode/*
В основном очищает кеши Xcode и производные данные, которые иногда повреждаются. Надеюсь, это сработает для вас.