2015-08-06 2 views
17

Я получил это сообщение при тестировании моего приложения на тренажере:Xcode «Сообщение от отладчика: получило неожиданный ответ на K пакета: OK»

Сообщение от отладчика: получил неожиданный ответ на K пакета: OK

Что это значит и является моим приложением в какой-либо опасности?

Использование Xcode 6.4 & 7,2

+0

Предполагаем ли вы, что делает ваш код? Покажите соответствующие части ответственности. –

+0

Проводка не имеет значения из-за того, что я понятия не имею, что такое k-пакет и какой код он может ссылаться на это сообщение. Это не крушение - только это сообщение, которого я никогда не видел. – noobsmcgoobs

+0

Если код неактуальен, то я предполагаю, что сообщение тоже ... –

ответ

2

Это Xcode "шалят". Я также получил его один раз и установил ее, выполнив это в терминале:

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

основном очищает Xcode кэшей и производные данные, которые иногда получают коррумпированные. Надеюсь, это сработает для вас.

+0

Я попробую, если это произойдет снова. Вы знаете, что такое 'k пакет'? – noobsmcgoobs

+0

@noobsmcgoobs Да, я собираюсь узнать, что это такое. – AntiMoron

4

Если вы посмотрите на файл 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.