Xcode "Messaggio da debugger: ottenuto risposta inattesa ak pacchetto: OK"

Question

ho ricevuto questo messaggio quando si prova la mia applicazione sul simulatore:

Messaggio del debugger: ottenuto risposta inattesa ak pacchetto: OK

Che cosa significa e la mia app è in pericolo?

Utilizzando Xcode 6,4 & 7,2

Answer 1

E 'Xcode "agire up". Ho anche avuto una volta e riparato eseguendo questo nel terminale:

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

cancella Fondamentalmente cache Xcode e dati derivati ​​che a volte ottenere corrotti. Spero che funzioni per te.

Answer 2

Se si guarda il file ProcessGDBRemote.cpp nel codice sorgente LLVM, si vedrà che questo si verifica quando v'è una risposta inaspettata da processo di debugger di Xcode, in questo caso, se il pacchetto non è il 'W' o 'X' caratteri:

In questo caso il debugger invia la stringa "OK" anziché "W" o "X". Non c'è niente che puoi fare, c'è un problema dietro le quinte in Xcode. Ho scoperto che una combinazione di uccisione dei processi di debug di Xcode, riavvio di Xcode e riavvio del computer prima di ricollegarsi a una sessione di debug può risolvere questo problema.

Per saperne di più su processi nativi su OS X, check-out il commento all'interno di quella annidata if dichiarazione:

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

utili commenti sul perché si potrebbe verificare questo errore:

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