2014-10-23 19 views
5

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

+1

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). –

+1

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

+0

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

risposta

3

è necessario digitare process handle SIGSEGV --notify true --pass true --stop true su lldb in base a this.

(lldb) handle di processo SIGSEGV --notify vero --pass vero --stop vero

+0

Sembra ragionevole - ma in realtà non funziona nel mio caso, non ho idea del perché. – qdot

+1

Esegui l'applicazione su un target remoto? Avevo un problema simile quando eseguivo il debug di un'applicazione C tramite JTAG su un target remoto. Ho dovuto usare OpenOCD per ottenere quello che mi serve. Ma non penso che questo sia il tuo caso, giusto? – VivienG

+0

Target locale, un po 'strano punto di ingresso dell'applicazione (tentativo di scrivere un'estensione dell'applicazione principalmente in C++ per riutilizzare il codice Linux/Win32) – qdot

0

Ho fatto un programma di test rapido,

#include <signal.h> 
#include <stdio.h> 
#include <unistd.h> 

void handler (int in) 
{ 
    puts ("signal received"); 
} 

int main() 
{ 
    signal (SIGSEGV, handler);  
    kill (getpid(), SIGSEGV); 
    return 0; 
} 

poi cerco debugging dove dico lldb a fermarsi su SIGSEGV:

(lldb) br s -n main 
(lldb) r 
(lldb) pr h -p true -n true -s true SIGSEGV 
NAME  PASS STOP NOTIFY 
========== ===== ===== ====== 
SIGSEGV  true true true 
(lldb) c 
Process 5024 resuming 
Process 5024 stopped 

(lldb) bt 
* thread #1: tid = 0x19d6ae, 0x00007fff8f27fc7e libsystem_kernel.dylib`__kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV 
    * #0: 0x00007fff8f27fc7e libsystem_kernel.dylib`__kill + 10 
    #1: 0x0000000100000f25 a.out`main + 53 at a.c:13 
    #2: 0x00007fff8c0e65c9 libdyld.dylib`start + 1 
(lldb) c 
Process 5024 resuming 
signal received 
Process 5024 exited with status = 0 (0x00000000) 
(lldb) 

OK in modo che assomiglia a quello che abbiamo Expec ted. Posso anche chiedere lldb a trasmettere solo il segnale senza fermarsi:

(lldb) br s -n main 
(lldb) r 
(lldb) pr h -p true -n true -s false SIGSEGV 
NAME  PASS STOP NOTIFY 
========== ===== ===== ====== 
SIGSEGV  true false true 
(lldb) c 
Process 5055 resuming 
Process 5055 stopped and restarted: thread 1 received signal: SIGSEGV 
signal received 
Process 5055 exited with status = 0 (0x00000000) 
(lldb) 

e che sembra che ha fatto quello che volevamo: lldb ci ha comunicato che il segnale è stato ricevuto e poi inviato al programma.

Questo è su Mac OS X con Xcode 6 installato.