le tracce di stack si fermano prima di arrivare al mio codice (su Android utilizzando NDK)

Sto sviluppando su Android 2.3.x utilizzando NDK r5b. Di tanto in tanto il mio codice si blocca e vorrei sapere where. So già come get la corrispondente row nella mia applicazione quando ho un puntatore (ad esempio dalle tracce dello stack di Android).

Tuttavia, spesso vedo tracce di stack inutili come questo (tracce di stack pieno):

  • managedQuery () vs context.getContentResolver.query () vs android.provider.something.query ()
  • Come iniziare con SQLCipher per Android?
  • AndroId MediaPlayer prepareAsync metodo
  • "IllegalArgumentException: bad base-64" durante il tentativo di utilizzare Base64 su Android 1.5
  • Come sviluppare un analizzatore di spettro da un audio in tempo reale?
  • Android ha impostato il GridView per avere solo 2 colonne per row
  • #00 pc 0006561a /system/lib/egl/libGLESv2_adreno200.so #01 pc 0006b900 /system/lib/egl/libGLESv2_adreno200.so #02 pc 0005aac8 /system/lib/egl/libGLESv2_adreno200.so #03 pc 0001687a /system/lib/egl/libGLESv1_CM_adreno200.so #04 pc 000096ce /system/lib/egl/libGLESv1_CM_adreno200.so 

    o questo:

     (gdb) bt #0 0xafd0c51c in epoll_wait () from /Volumes/SecureCode/webos/rta/android/obj/local/armeabi/libc.so #1 0xa81216a6 in ?? () 

    che non menzionano nemless il mio codice.

    C'è un modo per get migliori tracce di stack di questo? Perché alcune funzioni della libreria "opachi" in quanto non consentono alla backtrace di "vedere" la function chiamante, causando una sosta nella traccia dello stack?

    Per quanto posso dire, l'unico modo per eseguire il debug di un problema come questo è quello di utilizzare la logging in each punto del programma e / o passare attraverso each row con gdb.

    Ci sono ROM disponibili con versioni di debug di queste librerie Android anziché quelle di runtime e che potrebbero aiutare? (Uso un telefono solo per lo sviluppo, quindi non sono preoccupato di mantenere la piena funzionalità.) ( In realtà , ho notato che il path di libc.so nella traccia sopra lo stack gdb è all'interno della mia directory di applicazioni. con un diverso (debug) libc.so , e che avrebbe aiutato?)

    Un'ultima cosa che potrebbe aiutare: nella suddetta traccia di stack da logcat (la prima), la mia libreria è menzionata nel dump di stack crudo:

     stack: ... ... 4471cb88 00000028 4471cb8c afd4649c 4471cb90 80b4eb71 /data/data/com.audia.dev.rta/lib/librta.so 4471cb94 00299180 ... ... 

    ma questo non è un puntatore di function. Che cosa potrebbe essere, e sarebbe di aiuto dopo che l'applicazione si è schiantata? Sto indovinando probabilmente non se è un puntatore di heap o qualcosa del genere.

  • Aiutiamo a ridurre la dimensione apam Xamarin.Android
  • Formato file di traccia di Systrace Android
  • C'è un modo per testare il multi-touch sull'emulatore Android?
  • La richiesta non è rioutput: java.net.socketexception: La famiglia di indirizzi non è supportta dal protocollo
  • Parser di SAX: recupero dei tag HTML da XML
  • Definizione dynamic e utilizzo di selettori
  • 5 Solutions collect form web for “le tracce di stack si fermano prima di arrivare al mio codice (su Android utilizzando NDK)”

    C'è un modo per get migliori tracce di stack di questo?

    Per quanto ne so, dovrai build e scrivere l'image Android da solo. Consente di avere tutti i simboli completi di Android (file eseguibili e librerie condivise) ad exception delle librerie condivise di properties;.

    • Costruire dalla fonte – compilare il CyanogenMod da Source

    Inoltre prevede di utilizzare i simboli usando gdb.

     $ adb shell setprop debug.db.uid 32767 $ adb forward tcp:5039 tcp:5039 /* program terminated and debuggerd caught exception like the following. Use the PID number for gdbclient 3rd parameter. I/DEBUG ( 2154): ******************************************************** I/DEBUG ( 2154): * Process 2508 has been suspended while crashing. To I/DEBUG ( 2154): * attach gdbserver for a gdb connection on port 5039: I/DEBUG ( 2154): * I/DEBUG ( 2154): * adb shell gdbserver :5039 --attach 2508 & I/DEBUG ( 2154): * I/DEBUG ( 2154): * Press HOME key to let the process continue crashing. I/DEBUG ( 2154): ********************************************************) */ $ gdbclient "" "" 2508 

    MODIFICATO:

    È comunque ansible utilizzare ndk-gdb invece di command gdbclient. Specificare i file dei simboli per le librerie condivise.

     (gdb) set solib-search-path (ANDROID_SOURCE_PATH)/out/target/product/(PRODUCT_NAME)/symbols/system/lib 

    EDITO 2:

    Se non hai bisogno dei simboli delle librerie condivise del sistema Android, basta pubblicare le librerie condivise e impostare il path di ricerca di sollib.

     $ adb pull /system/lib lib $ ndk-gdb ... (gdb) set solib-search-path lib 

    Coppia di note:

    • In alcuni casi, la tua traccia di stack potrebbe essere danneggiata perché il tuo stack è stato parzialmente trashed. Poco probabile.
    • Qual è il sistema operativo utilizzato? Gingerbread (Android 2.3) è molto migliore in termini di tracce di stack. Se non si utilizza Android 2.3, trovare una versione Android 2.3 per il tuo telefono da qualche parte, o get un telefono di sviluppo economico che funziona 2.3.
    • Hai visto lo script di Onur ? Sta funzionando molto bene per me, anche su telefoni Android 2.2.
    • Spero che fadden sta leggendo questo, sono sicuro che abbia una risposta molto più utile del mio.

    Verifica la seguente domanda: Come generare una stacktrace quando il mio app gcc C ++ si blocca

    Abbiamo fatto lo stesso con la nostra applicazione Android: abbiamo scritto il nostro gestore di segnali, gestito i segnali 7 (sigbus) e 11 (sigsegv) e printingto la stack tace dal gestore. Non abbiamo utilizzato la function backtrace (), ma abbiamo spostato manualmente lo stack …

    Combinando le prime due risposte si dovrebbe essere in grado di scrivere il proprio gestore di segnali per scaricare la traccia dello stack. Questo articolo può anche aiutarti a: http://www.ibm.com/developerworks/power/library/l-sigdebug/index.html . Tenga presente che l'estrazione del contenuto del registro è dipendente dall'architettura, per cui è necessario sostituire le strutture utilizzate nei codici di cui sopra con quelli su android (dipendenti dal processre ARM). Per esempio ho dovuto scavare nella sorgente Android per 'struct ucontext'.

    Quando hai la traccia dello stack, esegui uno script sull'output, che risolve i simboli utilizzando addr2line e il tuo eseguibile non eseguito.

    Spiacenti di inondare la mia domanda con le risposte, ma ho scoperto che l'integrazione di Google Breakpad è stato un ottimo modo per get buone tracce di stack / rapporti di crash. È facile scrivere un gestore di segnali che chiama Breakpad e che si occupa di tutto; dobbiamo solo caricare i rapporti sul nostro server. Abbiamo anche integrato il process di call stackwalk.sh nel nostro sistema di compilazione. Ci sono voluti un po 'di lavoro, ma è tutto perfetto per get buoni rapporti di crash nativi su Android.

    Questa risposta ha alcuni dettagli sulla scrittura di un gestore di segnali; il resto del codice necessario è sul sito Google Breakpad sotto la wiki.

    Ho ricevuto una risposta a questa domanda per alcune tracce di stack. (Dall'aspetto di questa domanda che può essere tutto quello che ottengo.) Questi sono quelli che terminano con un indirizzo lr (link register). Vedi la mia altra domanda / risposta .

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.