Program received signal: “EXC_BAD_ACCESS”.
[Switching to process 388]
kill
error while killing target (killing anyway): warning: error on line 2179 of "/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
quit
The Debugger has exited with status 0.(gdb)
Segnale ricevuto programma: "EXC_BAD_ACCESS". [Passare al processo 388] uccidere l'errore mentre si uccide il target (omissione comunque): avviso: errore sulla riga 2179 di "/ SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c " in funzione "macosx_kill_inferior_safe": (OS/Kern) fallimento (0x5x) quit
Nota dove l'errore è; gdb si è arrestato in modo anomalo. Ciò è potenzialmente dovuto a un arresto anomalo dell'applicazione, ma determinati messaggi non sono certamente utili per il debug del problema reale.
E, più probabile che no, il crash effettivo ha niente da fare con una sovraelencazione di un oggetto,. Forse sì, ma probabilmente no.
In genere, quando GDB si interrompe in questo modo, è perché si è eliminato l'heap o lo stack in modo tale che gdb interrompa la corruzione cercando di capire cosa sta succedendo. Oppure la tua app è entrata in uno stato in cui gdb non può più comunicare con esso (che potrebbe essere il caso qui dato la posizione di arresto anomalo).
In questo caso, alcune cose da provare:
utilizzando le più recenti strumenti di sviluppo? In caso contrario, fallo e ricostruisci la tua app anche da pulita.
l'arresto anomalo può essere riprodotto sul simulatore e sul dispositivo? Se è così, può essere debugato correttamente su uno, ma non sull'altro?
se si esegue l'applicazione senza il debugger, è possibile farlo arrestarsi e quindi estrarre il registro di arresto anomalo dal dispositivo?
cambia il comportamento tra build di debug e non di debug? Ciò può avere un forte impatto sulla corruzione della memoria.
ha appena iniziato? Se sì, cosa hai cambiato più recentemente?
Pensato a un altro trucco;
MallocScribble. Questo scaraboccherà i valori in memoria al momento dell'assegnazione/deallocazione e può spesso, almeno, causare un arresto anomalo della corruzione della memoria prima o abbastanza diverso da catturarlo.sicuramente amano la tua risposta! – jakev
Ho finito per svalutare il resto delle risposte ... non erano * giuste * ma non erano nemmeno punibili. Questo è uno di quei ** bug duri **. Se avessi fatto uno sviluppo diretto come un nuovo arrivato relativo e si fosse imbattuto in una situazione come questa, l'assunzione di una sovra-release sarebbe stata facile e naturale ... e del tutto sconcertante mentre cercavi di capire cosa diavolo sta succedendo davvero . – bbum
+1 per @ bbum, causa principalmente a causa del rilascio anticipato o eccessivo ...... – Sabby
EXC_BAD_ACCESS significa in genere che si sta tentando di accedere a qualcosa che non esiste più. Avremmo bisogno del tuo stack dump e probabilmente del codice per aiutarti a capirlo.
come ottengo quello? – testndtv
EXC_BAD_ACCESS significa solo che a volte; a volte significa che sei incappato nella memoria corrotta. E, in questo caso, è il crash del debugger che significa che il crash nell'app originale probabilmente non è il tipico problema di rilascio/rilascio. – bbum
perché il debugger si blocca, cosa potrebbe andare storto che non proviene da un errore nel codice dell'op? – jakev
Per citare un collega, "Qualcosa è andato storto da qualche parte".
Ciò significa che si è tentato di accedere a un puntatore non più valido. Forse hai dimenticato di conservare un oggetto o lo hai rilasciato troppe volte?
No: questa sequenza indica che ** gdb ** si è arrestato in modo anomalo. Probabilmente l'app si è bloccata per prima e quello era il grilletto, ma nessuno di ciò che viene pubblicato fornisce indizi su cosa è andato storto. Il fatto che il debugger si sia arrestato probabilmente significa che l'app ha danneggiato la memoria al di sopra e al di là di una semplice sovra-release. – bbum
Grazie per il chiarimento! –
Definitivamente una domanda molto reale; Ho visto casi come questo in cui si tratta della totalità dell'identità fornita. Una difficile. – bbum