Proveniente dal mondo Linux/gdb, il file gdb di default interrompe l'esecuzione del programma al rilevamento di un SEGV, prima che il gestore predefinito pulisca il processo.lldb break upon SIGSEGV
Come può lldb eseguire il trucco simile? Attualmente il processo appena esce, rendendo impossibile interrogare il backtrace ecc
Edit: proccess handle -p true -n true -s true
tentato - senza risultato :(
(lldb) process handle -p true -n true -s true SIGSEGV
NAME PASS STOP NOTIFY
========== ===== ===== ======
SIGSEGV true true true
(lldb) run
Process 97630 launched: '/Volumes/My Finder Extensions 1/My_Daemon.app/Contents/PlugIns/My_ShellExt.appex/Contents/MacOS/My_ShellExt' (x86_64)
Process 97630 exited with status = 0 (0x00000000) Terminated due to signal 9
Edit: maggiori informazioni:
(lldb) bt all
error: invalid thread
Ho il sospetto che lo lldb
non funzioni con corrotto ed stack - Sto cercando di rintracciare un problema che coinvolge un punto di ingresso _NSExtensionMain
o qualcosa in fondo alla linea da lì.
Sei sicuro che il tuo programma sta ricevendo un SIGSEGV? Il segnale 9 è SIGKILL e non può essere catturato da un debugger (a meno che, possibilmente, non ci sia un modo specifico per Mach di farlo). –
Qui sta succedendo qualcosa di strano. Abbiamo ottenuto uno stato di uscita (0) per il processo, quindi in realtà è uscito normalmente. Non so perché pensiamo anche che abbia un segnale 9. BTW, se esegui il debug di un programma e ottiene un SIGKILL, si fermerà nel debugger con SIGKILL. Il debugger può catturare SIGKILL, ciò che non può fare è sopprimerli. –
E 'possibile provare un debug passo dopo passo? Penso che il tuo programma sovrascriva una parte di "dati sensibili" come IVT o PCB, questo potrebbe essere il motivo per cui non puoi fare "backtrace". – VivienG