Come posso rilevare SIGSEGV (errore di segmentazione) e ottenere una traccia dello stack sotto JNI su Android?

Sto spostando un progetto nel nuovo Android Native Development Kit (cioè JNI) e vorrei catturare SIGSEGV, se dovesse verificarsi (possibilmente anche SIGILL, SIGABRT, SIGFPE) per presentare una bella finestra di dialogo di segnalazione di crash, invece di (o prima) ciò che accade attualmente: la morte immediata e senza cerimonie del processo e forse qualche tentativo da parte del sistema operativo di riavviarlo. ( Modifica: la VM JVM / Dalvik cattura il segnale e registra una traccia dello stack e altre informazioni utili; Voglio solo offrire all'utente la possibilità di inviarmi queste informazioni tramite e-mail.)

La situazione è: una grande quantità di codice C che non ho scritto fa la maggior parte del lavoro in questa applicazione (tutta la logica del gioco) e sebbene sia ben testato su numerose altre piattaforme, è del tutto possibile che io, nel mio Android port, alimenterà la spazzatura e causerà un arresto anomalo nel codice nativo, quindi voglio i dump di arresto anomalo (sia nativi che Java) che attualmente vengono visualizzati nel registro di Android (immagino che sarebbe stderr in una situazione non Android). Sono libero di modificare arbitrariamente sia il codice C che Java, sebbene i callback (sia in entrata che in uscita da JNI) siano circa 40 e, ovviamente, punti bonus per piccole differenze.

Ho sentito parlare della libreria di concatenamento del segnale in J2SE, libjsig.so, e se potessi installare in sicurezza un gestore di segnali come quello su Android, risolverebbe la parte interessante della mia domanda, ma non vedo tale libreria per Android / Dalvik .

Modifica: da Jelly Bean in poi non è possibile ottenere la traccia dello stack, perché è READ_LOGSandato via . :-(

In realtà ho un gestore di segnali che funziona senza fare nulla di troppo esotico e ho rilasciato del codice che lo utilizza, che puoi vedere su GitHub (modifica: collegamento alla versione storica; da allora ho rimosso il gestore dei crash). Ecco come:

1. Utilizzare sigaction()per catturare i segnali e memorizzare i vecchi gestori. ( android.c: 570 )
2. Il tempo passa, accade un segfault.
3. Nel gestore del segnale, chiama JNI un'ultima volta e poi chiama il vecchio gestore. ( android.c: 528 )
4. In quella chiamata JNI, registra tutte le informazioni di debug utili e chiama startActivity()un'attività contrassegnata come necessaria nel proprio processo. ( SGTPuzzles.java:962 , AndroidManifest.xml: 28 )
5. Quando torni da Java e chiami quel vecchio gestore, il framework Android si connetterà a debuggerdper registrare una bella traccia nativa per te, e quindi il processo morirà. ( debugger.c , debuggerd.c )
6. Nel frattempo, inizia la tua attività di gestione degli incidenti. In realtà dovresti passargli il PID in modo che possa attendere il completamento del passaggio 5; Io non lo faccio. Qui ti scusi con l'utente e chiedi se puoi inviare un log. In tal caso, raccogliere l'output di logcat -d -v threadtimee avviare un messaggio ACTION_SENDcon destinatario, oggetto e corpo compilati. L'utente dovrà premere Invia. ( CrashHandler.java , SGTPuzzles.java:462 , strings.xml: 41
7. Fai attenzione se logcatfallisci o impieghi più di pochi secondi. Ho incontrato un dispositivo, il T-Mobile Pulse / Huawei U8220, in cui logcat entra immediatamente nello stato T(tracciato) e si blocca. ( CrashHandler.java:70 , strings.xml: 51 )

In una situazione non Android, alcuni di questi sarebbero diversi. Dovresti raccogliere la tua traccia nativa, vedere quest'altra domanda , a seconda del tipo di libc che hai. Dovresti gestire il dumping di quella traccia, avviare il tuo processo di gestione degli arresti anomali separato e inviare l'e-mail in alcuni modi appropriati per la tua piattaforma, ma immagino che l'approccio generale dovrebbe ancora funzionare.

Sono un po 'in ritardo, ma ho avuto la stessa necessità, e ho sviluppato una piccola biblioteca per affrontarlo, con la cattura di crash comuni ( SEGV, SIBGUS, ecc) all'interno del codice JNI , e li sostituisce con regolari java.lang.Error eccezioni . Bonus, se il client è in esecuzione su Android> = 4.1.1, la traccia dello stack incorpora il backtrace risolto del crash (una pseudo-traccia contenente la traccia dello stack nativa completa). Non ti riprenderai da arresti anomali (ad esempio se corrompi l'allocatore, per esempio), ma almeno dovrebbe permetterti di ripristinarli dalla maggior parte di essi. (si prega di segnalare successi e fallimenti, il codice è nuovo di zecca)

Maggiori informazioni su https://github.com/xroche/coffeecatch (il codice è la licenza BSD a 2 clausole )

FWIW, Google Breakpad funziona bene su Android. Ho eseguito il porting e lo spediremo come parte di Firefox Mobile. Richiede una piccola configurazione, dal momento che non ti dà tracce dello stack sul lato client, ma ti invia la memoria dello stack non elaborato e fa lo stack walking lato server (quindi non devi spedire simboli di debug con la tua app ).

Nella mia esperienza limitata (non Android), SIGSEGV nel codice JNI generalmente bloccherà la JVM prima che il controllo venga restituito al codice Java. Ricordo vagamente di aver sentito parlare di una JVM non Sun che ti consente di catturare SIGSEGV, ma AFAICR non puoi aspettarti di poterlo fare.

Puoi provare a catturarli in C (vedi sigaction (2)), sebbene tu possa fare molto poco dopo un gestore SIGSEGV (o SIGFPE o SIGILL) poiché il comportamento in corso di un processo è ufficialmente indefinito.