Segnale fatale Android 11 (SIGSEGV) a 0x636f7d89 (codice = 1). Come può essere rintracciato?

Ho letto gli altri post per rintracciare i motivi per ottenere un SIGSEGVin un'app Android. Ho in programma di cercare la mia app per possibili NullPointer relativi all'uso di Canvas, ma SIGSEGVogni volta il mio barfigura un indirizzo di memoria diverso. Inoltre ho visto code=1e code=2. Se l'indirizzo di memoria fosse 0x00000000, avrei idea che sia un NullPointer.

L'ultimo che ho ricevuto è stato un code=2:

A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)

Qualche suggerimento su come rintracciarlo?

Ho un sospetto, ma non mi interessa ancora sperimentarlo. La mia app utilizza l'API OSMDroid per il mapping offline. La classe OverlayItem rappresenta marcatori / nodi sulla mappa. Ho un servizio che raccoglie i dati tramite la rete per popolare gli OverlayItem che vengono quindi visualizzati sulla mappa. Nel tentativo di semplificare la mia progettazione, ho esteso OverlayItem nella mia classe NodeOverlayItem, che include alcuni attributi aggiuntivi che utilizzo nell'attività dell'interfaccia utente e nel servizio. Ciò mi ha fornito un unico punto di informazioni sull'articolo per l'interfaccia utente e il servizio. Ho usato Intents per trasmettere all'attività per aggiornare la mappa dell'interfaccia utente quando qualcosa è cambiato. L'attività si lega al servizio e esiste un metodo di servizio per ottenere l'elenco di NodeOverlayItem. Penso che potrebbe essere l'uso dell'API OSMDroid di OverlayItem, e il mio servizio aggiornando contemporaneamente le informazioni sul nodo. (un problema di concorrenza)

Mentre scrivo questo penso che sia davvero il problema. Il mal di testa non sta dividendo Node e OverlayItem da NodeOverlayItem, è che l'attività avrà bisogno di alcuni dati dal Nodo, che il Servizio detiene. Inoltre, quando viene creata l'attività (onResume, ecc ...), gli oggetti OverlayItem dovranno essere ricreati dai dati del nodo che il servizio ha mantenuto mentre l'attività era assente. ad es. Avvia l'app, il servizio raccoglie i dati, l'interfaccia utente lo visualizza, vai su Home, quindi di nuovo sull'app, l'attività dovrà estrarre e ricreare gli OverlayItem dagli ultimi dati del nodo del servizio.

So che non sono domande grandiose o chiare. È come se tutte le mie domande SO fossero di nicchia o oscure. Se qualcuno ha un suggerimento su come interpretare quegli SIGSEGVerrori, sarebbe molto apprezzato!

AGGIORNAMENTO Ecco l'ultimo crash catturato durante una sessione di debug. Ho 3 di questi dispositivi utilizzati per i test e non si bloccano tutti in modo affidabile durante lo sviluppo e il test. Ho incluso un po 'di più solo per poter notare la registrazione GC. È possibile notare che il problema non è probabilmente correlato all'esaurimento della memoria.

03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712  >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008):  r0 68f52ab4  r1 412ef268  r2 4d9c3bf4  r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008):  r4 001ad8f8  r5 4d9c3bf4  r6 412ef268  r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008):  r8 4d9c3c0c  r9 4c479dec  10 46cf260a  fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008):  ip 40262a04  sp 4d9c3bc8  lr 402d01dd  pc 402d0182  cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008):  d0  00000001000c0102  d1  3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008):  d2  403fc0000000007d  d3  363737343433350a
03-03 02:02:38.914: I/DEBUG(4008):  d4  49544341223a2273  d5  6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008):  d6  3a223645676e6f4c  d7  000000013835372d
03-03 02:02:38.914: I/DEBUG(4008):  d8  0000000000000000  d9  4040000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d10 0000000000000000  d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d12 4040000000000000  d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008):  d14 0000000000000000  d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d16 3fe62e42fefa39ef  d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d18 3fe62e42fee00000  d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d20 0000000000000000  d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d22 4028000000000000  d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d24 0000000000000000  d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d26 0000000000000000  d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d28 0000000000000000  d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d30 3ff0000000000000  d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008):  scr 60000013
03-03 02:02:39.046: I/DEBUG(4008):          #00  pc 0006b182  /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008):          #01  pc 0006b1d8  /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008):          #02  pc 0001f814  /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008):          #03  pc 0001ec30  /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008):          #04  pc 00058c70  /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81  ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800  )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10  .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631  zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13  .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630  !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff  ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573  .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020  .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025  [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000 
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b88  408d1f90  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b8c  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b90  00000001  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b94  408d6c58  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b98  408d6fa8  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b9c  4c479dec  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba0  46cf260a  /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba4  408735e7  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba8  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bac  002bf070  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb0  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb4  00000000  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb8  412ef268  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bbc  00000000  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bc0  df0027ad  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bc4  00000000  
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8  001ad8f8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bcc  002ae0b8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bd0  00000004  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bd4  402d01dd  /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8  001ad8f8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bdc  002ae0b8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3be0  00000004  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3be4  4024e817  /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation

Innanzitutto, ottieni la traccia dello stack di tombstone, che verrà stampata ogni volta che l'app si arresta in modo anomalo. Qualcosa come questo:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086  >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
 r0 00000000  r1 00000001  r2 ad12d1e8  r3 7373654d
 r4 64696f72  r5 00000406  r6 00974130  r7 40d14008
 r8 4b857b88  r9 4685adb4  10 00974130  fp 4b857ed8
 ip 00000000  sp 4b857b50  lr afd11108  pc ad115ebc  cpsr 20000030
 d0  4040000040000000  d1  0000004200000003
 d2  4e72cd924285e370  d3  00e81fe04b1b64d8
 d4  3fbc71c7009b64d8  d5  3fe999999999999a
 d6  4010000000000000  d7  4000000000000000
 d8  4000000000000000  d9  0000000000000000
 d10 0000000000000000  d11 0000000000000000
 d12 0000000000000000  d13 0000000000000000
 d14 0000000000000000  d15 0000000000000000
 scr 80000012

         #00  pc 000108d8  /system/lib/libc.so
         #01  pc 0003724c  /system/lib/libxvi020.so
         #02  pc 0000ce02  /system/lib/libxvi020.so
         #03  pc 0000d672  /system/lib/libxvi020.so
         #04  pc 00010cce  /system/lib/libxvi020.so
         #05  pc 00004432  /system/lib/libwimax_jni.so
         #06  pc 00011e74  /system/lib/libdvm.so
         #07  pc 0004354a  /system/lib/libdvm.so
         #08  pc 00017088  /system/lib/libdvm.so
         #09  pc 0001c210  /system/lib/libdvm.so
         #10  pc 0001b0f8  /system/lib/libdvm.so
         #11  pc 00059c24  /system/lib/libdvm.so
         #12  pc 00059e3c  /system/lib/libdvm.so
         #13  pc 0004e19e  /system/lib/libdvm.so
         #14  pc 00011b94  /system/lib/libc.so
         #15  pc 0001173c  /system/lib/libc.so

code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e 
ad115eac 4605b570 447c4c0a f7f44620 e006edc8 
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2 
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70 
ad115edc 00017332 00017312 2100b51f 46682210 

code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004 
afd110f8 e2055a02 e1a00005 e3851001 ebffed92 
afd11108 e3500000 13856002 1a000001 ea000009 
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92 
afd11128 e1a01005 e1550000 e1a02006 e3a03000 

stack:
    4b857b10  40e43be8  
    4b857b14  00857280  
    4b857b18  00000000  
    4b857b1c  034e8968  
    4b857b20  ad118ce9  /system/lib/libnativehelper.so
    4b857b24  00000002  
    4b857b28  00000406

Quindi, utilizza l' addr2lineutilità (trovala nella tua catena di strumenti NDK) per trovare la funzione che si arresta in modo anomalo. In questo esempio, lo fai

addr2line -e -f libc.so 0001173c

E vedrai dove hai riscontrato il problema. Naturalmente questo non ti aiuterà dal momento che è in libc.

Quindi potresti combinare le utilità di arm-eabi-objdumpper trovare l'obiettivo finale.

Credetemi, è un compito difficile.

Solo per un aggiornamento. Penso che stavo realizzando la build nativa Android dall'albero dell'intera fonte per un bel po 'di tempo, fino ad oggi ho letto attentamente i documenti NDK. Sin dalla versione NDK-r6, ha fornito un'utilità chiamata ndk-stack.

Di seguito è riportato il contenuto dei documenti NDK ufficiali con la palla tar NDK-r9.

Panoramica:

ndk-stack è un semplice strumento che consente di filtrare le tracce dello stack come appaiono nell'output di 'adb logcat' e sostituire qualsiasi indirizzo all'interno di una libreria condivisa con i corrispondenti valori:.

In breve, tradurrà qualcosa del tipo:

  I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  I/DEBUG   (   31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  I/DEBUG   (   31): pid: 351, tid: 351  %gt;%gt;%gt; /data/local/ndk-tests/crasher <<<
  I/DEBUG   (   31): signal 11 (SIGSEGV), fault addr 0d9f00d8
  I/DEBUG   (   31):  r0 0000af88  r1 0000a008  r2 baadf00d  r3 0d9f00d8
  I/DEBUG   (   31):  r4 00000004  r5 0000a008  r6 0000af88  r7 00013c44
  I/DEBUG   (   31):  r8 00000000  r9 00000000  10 00000000  fp 00000000
  I/DEBUG   (   31):  ip 0000959c  sp be956cc8  lr 00008403  pc 0000841e  cpsr 60000030
  I/DEBUG   (   31):          #00  pc 0000841e  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #01  pc 000083fe  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #02  pc 000083f6  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #03  pc 000191ac  /system/lib/libc.so
  I/DEBUG   (   31):          #04  pc 000083ea  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #05  pc 00008458  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #06  pc 0000d362  /system/lib/libc.so
  I/DEBUG   (   31):

Nell'output più leggibile:

  ********** Crash dump: **********
  Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  pid: 351, tid: 351  >>> /data/local/ndk-tests/crasher <<<
  signal 11 (SIGSEGV), fault addr 0d9f00d8
  Stack frame #00  pc 0000841e  /data/local/ndk-tests/crasher : Routine zoo in /tmp/foo/crasher/jni/zoo.c:13
  Stack frame #01  pc 000083fe  /data/local/ndk-tests/crasher : Routine bar in /tmp/foo/crasher/jni/bar.c:5
  Stack frame #02  pc 000083f6  /data/local/ndk-tests/crasher : Routine my_comparison in /tmp/foo/crasher/jni/foo.c:9
  Stack frame #03  pc 000191ac  /system/lib/libc.so
  Stack frame #04  pc 000083ea  /data/local/ndk-tests/crasher : Routine foo in /tmp/foo/crasher/jni/foo.c:14
  Stack frame #05  pc 00008458  /data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
  Stack frame #06  pc 0000d362  /system/lib/libc.so

Uso:

Per fare ciò, avrai prima bisogno di una directory che contenga versioni simboliche delle librerie condivise della tua applicazione. Se si utilizza il sistema di generazione NDK (ovvero ndk-build), questi si trovano sempre in $ PROJECT_PATH / obj / local /, dove sta per ABI del dispositivo (ovvero armeabiper impostazione predefinita).

È possibile alimentare il logcattesto come input diretto al programma, ad esempio:

adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

Oppure puoi usare l'opzione -dump per specificare il logcat come file di input, ad esempio:

adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt

IMPORTANTE:

Lo strumento cerca la riga iniziale contenente gli inizi logcatnell'output, ovvero qualcosa che assomiglia a:

 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Quando si copia / incolla le tracce, non dimenticare questa linea dalle tracce o ndk-stacknon funzionerà correttamente.

FARE:

Una versione futura di ndk-stacktenterà di avviarsi adb logcate selezionare automaticamente il percorso della libreria. Per ora, dovrai eseguire questi passaggi manualmente.

A partire da ora, ndk-stacknon gestisce le librerie che non contengono informazioni di debug. Può essere utile provare a rilevare il punto di ingresso della funzione più vicino a un determinato indirizzo PC (ad es. Come nell'esempio libc.so sopra).

OK! Mi dispiace davvero per coloro che hanno effettivamente inviato commenti e risposte, ma ho riscontrato il problema. Non penso che questo aiuterà molti altri a cercare di rintracciare il loro SIGSEGV personale, ma il mio (ed è stato molto difficile) era interamente correlato a questo:

https://code.google.com/p/android/issues/detail?id=8709

Il libcrypto.so nel mio dump mi ha indotto a capire. Faccio un hash MD5 dei dati del pacchetto quando provo a determinare se ho già visto il pacchetto e saltandolo se ce l'ho. Ho pensato che a un certo punto si trattasse di un brutto problema di threading relativo al monitoraggio di quegli hash, ma si è scoperto che era la classe java.security.MessageDigest! Non è thread-safe!

L'ho scambiato con un UID che stavo inserendo in ogni pacchetto basato sull'UUID del dispositivo e su un timestamp. Nessun problema da allora.

Immagino che la lezione che posso impartire a coloro che erano nella mia situazione sia, anche se sei un'applicazione Java al 100%, presta attenzione alla libreria nativa e al simbolo annotati nella discarica per indizi. Googling per SIGSEGV + il nome lib .so andrà molto più lontano del codice inutile = 1, ecc ... Ora pensa a dove la tua app Java potrebbe toccare il codice nativo, anche se non sta facendo nulla. Ho fatto l'errore di presumere che si trattasse di un problema di threading Service + UI in cui il Canvas stava disegnando qualcosa che era null, (il caso più comune che ho cercato su SIGSEGV su Google) e ho ignorato la possibilità che potesse essere completamente correlato al codice che ho scritto che era correlato alla lib .so nella discarica. Naturalmente java.security userebbe un componente nativo in libcrypto.so per la velocità, quindi una volta che mi sono accorto, ho cercato su Google + Android + SIGSEGV + libcrypto. così e ho trovato il problema documentato. In bocca al lupo!

Stavo ottenendo questo errore salvando un oggetto nelle preferenze condivise come una stringa convertita gson. La stringa gson non andava bene, quindi recuperare e deserializzare l'oggetto non funzionava correttamente. Ciò significava che qualsiasi accesso successivo all'oggetto causava questo errore. Spaventoso :)

Ho anche ricevuto questo errore molte volte e l'ho risolto. Questo errore verrà affrontato in caso di gestione della memoria nel lato nativo.

L'applicazione accede alla memoria al di fuori del suo spazio degli indirizzi. Questo è probabilmente un accesso al puntatore non valido. SIGSEGV = errore di segmentazione nel codice nativo. Dal momento che non si verifica nel codice Java, non vedrai una traccia dello stack con i dettagli. Tuttavia, è possibile che vengano visualizzate alcune informazioni di traccia dello stack nel logcat se ci si guarda un po 'dopo il crash del processo dell'applicazione. Non ti dirà il numero di riga all'interno del file, ma ti dirà quali file oggetto e indirizzi erano in uso nella catena di chiamate. Da lì puoi spesso capire quale area del codice è problematica. Puoi anche impostare una connessione nativa gdb al processo di destinazione e catturarla nel debugger.

Oggi ho affrontato il Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161problema e faccio fatica mezza giornata per risolverlo.

Ho provato molte cose cancellando la cache ed eliminando il file .gradle e tutto il resto.

Finalmente io disable Instant Rune ora non ho più questo problema. Ora la mia applicazione funziona anche dopo aver abilitato l'esecuzione istantanea. Potrebbe essere il problema della corsa istantanea. Prova a disabilitare e abilitare la corsa istantanea

Da questa risposta:

Vai su Impostazioni o Preferenze di Android Studio (per MAC) -> Build, Execution, Deployment -> Instant Run.

Quindi deseleziona la casella di controllo "Abilita esecuzione immediata" nella parte superiore.

Prova a disabilitare l'accelerazione hardware Android nel tuo manifest.

android:hardwareAccelerated="false"

Ho riscontrato questo errore quando ho provato ad accedere al 'canvas' al di fuori di onDraw()

    private Canvas canvas;

    @Override
    protected void onDraw(Canvas canvas) {
        this.canvas = canvas;
        ....... }

    private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
        @Override
        public boolean onScale(ScaleGestureDetector detector) { 
            canvas.save(); // here

Una brutta pratica: /

Stavo ottenendo questo errore quando si utilizzava una bitmap come questa:

bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);

Ciò che risolveva il problema per me era ridurre la dimensione della bitmap (> 1000px alta a 700px).

Ho affrontato SIGSEGV su Android 4.4.4 (Nexuses, Samsungs) E si è scoperto che l'errore fatale era durante l'analisi null StringusandoDecimalFormat

 static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
 void someMethod(String value) {
...
    Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}

Su Android> 21 è stato gestito con successo con try / catch

Ho affrontato questo problema un momento fa, dopo la migrazione da android.supporta androidx.

Il problema era renderscript.

Soluzione: ho rimosso dalle mie build.gradledue righe:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

dopo che la costruzione di quel progetto fallì, a causa di riferimenti irrisolti:

import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;

quindi li ho cambiati in:

import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

Dopo ciò tutti i problemi erano spariti.

Se si utilizza la libreria vitamio e si verifica questo errore fatale.

Quindi assicurati che nel tuo progetto grado targetSdkVersion deve essere inferiore a 23.

Grazie.

Nel mio caso (sto usando Xamarin Forms) questo errore è stato generato a causa di un errore di associazione, ad esempio:

<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center"  VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>

Fondamentalmente ho eliminato la proprietà del modello di visualizzazione per errore. Per gli sviluppatori Xamarin, se hai lo stesso problema, controlla i tuoi collegamenti ...

Se hai aggiunto del codice C nativo al tuo progetto, questa risposta potrebbe essere utile.

Avevo aggiunto del codice C nativo nel progetto Android.

Ora stavo cercando di accedere a quel codice che mi stava restituendo una stringa nativa, prima di elaborare la stringa avevo impostato il suo valore predefinito come nullptr. Ora, dopo aver recuperato il suo valore nel codice Java, ho riscontrato questo problema.

Dato che il nostro codice C nativo è uscito dalla directory java, quindi non ho idea della riga esatta del codice che sta creando il problema. Quindi ti consiglio di controllare il tuo file .cpp e provare a trovare qualche indizio lì.

Spero che ti libererai presto del problema. :)

Nel mio caso il problema è stato causato da Android Profiler. In Android Studio, fai clic su "Android Profiler" e "termina sessione".

Ironia della sorte, stava anche causando problemi di prestazioni estreme nell'applicazione.

Aggiungi queste due righe al tuo build.gradle nella sezione Android:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

Controlla il tuo codice JNI / nativo. Uno dei miei riferimenti era nullo, ma era intermittente, quindi non era molto ovvio.

controlla le tue funzioni native, se restituisce correttamente o no, se non viene restituito, aggiungi le dichiarazioni di reso.

Per me quel problema era dovuto a un cattivo cast tra due attività. Di recente ho spostato questo metodo da Activity1 ad un altro 2. In questo modo, il refactor ha lasciato questo cast esplicito come era prima. Quindi invece di farlo

((Activity1) mainActivity).hideDialog();

Dovevo farlo

((Activity2) mainActivity).hideDialog();

Nota: ma questo errore non si è verificato su Android 8.0 non sono ancora sicuro del perché.

*** Spero che sia d'aiuto.

Ho riscontrato questo errore di segmentazione a causa di problemi di memoria . La mia struttura con molte variabili e matrici aveva questa matrice di dimensioni 1024.

Riducendo la dimensione a 512, l'errore era sparito.

PS: questa è una soluzione alternativa e non una soluzione. È necessario trovare la dimensione della struttura e l'allocazione dinamica della memoria è un'opzione migliore.

Ho ricevuto questo errore quando ho usato ViewTreeObserver all'interno della onDraw()funzione.

@Override
protected void onDraw(Canvas canvas) {
    // super.onDraw(canvas);
    ViewTreeObserver vto = mTextView.getViewTreeObserver();
    vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // some animation        
        }
    });
 }

Ho avuto questo problema con un pacchetto che è stato aggiunto alla mia app (FancyShowCaseView) e ha causato questo problema su pre-lolipop. quel pacchetto è stato scritto in kotlin e i miei codici principali sono stati scritti in java. quindi ora sto controllando la versione in pre-lolipop e non consento l'esecuzione della sua classe. risolto temporaneamente il problema. controlla se hai problemi simili come me

Costruire impronta digitale: 'motorola / harpia / harpia: 6.0.1 / MPIS24.241-2.50-16 / 16: user / release-keys' Revisione: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, nome: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< segnale 11 (SIGSEGV), codice 2 (SEGV_ACCERR), errore aggiuntivo 0x7452f000

2 telefoni su 12 hanno restituito un errore, hanno riscontrato che il problema era in onDrawFrame (), alcuni oggetti erano nulli, non so perché, ho appena impostato

if(gears==null) return;.

Ho avuto il problema quando stavo creando un PDF usando le API PDF di Android e ho usato accidentalmente canvas.save () e canvas.restore () dopo aver chiuso una pagina pdf.