Android Fatal Signal 11 (SIGSEGV) bei 0x636f7d89 (Code = 1). Wie kann es aufgespürt werden?

221

Ich habe die anderen Beiträge über das Aufspüren der Gründe für das Erhalten einer SIGSEGVin einer Android-App gelesen . Ich habe vor, meine App nach möglichen Null-Zeigern im Zusammenhang mit der Verwendung von Canvas zu SIGSEGVdurchsuchen , aber meine Barfs haben jedes Mal eine andere Speicheradresse. Außerdem habe ich gesehen code=1und code=2. Wenn die Speicheradresse 0x00000000wäre, hätte ich eine Ahnung, dass es sich um einen NullPointer handelt.

Der letzte, den ich bekam, war code=2:

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

Irgendwelche Vorschläge, wie man das aufspürt?

Ich habe einen Verdächtigen, aber ich bin noch nicht daran interessiert, damit zu experimentieren. Meine App verwendet die OSMDroid-API für die Offline-Zuordnung. Die OverlayItem-Klasse repräsentiert Markierungen / Knoten auf der Karte. Ich habe einen Dienst, der Daten über das Netzwerk sammelt, um das OverlayItem zu füllen, die dann auf der Karte angezeigt werden. Um mein Design zu vereinfachen, habe ich OverlayItem in meine eigene NodeOverlayItem-Klasse erweitert, die einige zusätzliche Attribute enthält, die ich in der UI-Aktivität und im Service verwende. Dies gab mir einen einzigen Punkt mit Artikelinformationen für die Benutzeroberfläche und den Service. Ich habe Absichten verwendet, um an die Aktivität zu senden und die UI-Karte zu aktualisieren, wenn sich etwas geändert hat. Die Aktivität ist an den Service gebunden und es gibt eine Service-Methode, um die Liste der NodeOverlayItems abzurufen. Ich denke, es könnte die Verwendung von OverlayItem durch die OSMDroid-API sein. und mein Dienst aktualisiert gleichzeitig die Knoteninformationen. (ein Problem mit der Parallelität)

Während ich das schreibe, denke ich, dass das wirklich das Problem ist. Die Kopfschmerzen teilen nicht den Knoten und das OverlayItem von NodeOverlayItem auf, sondern die Aktivität benötigt einige Daten vom Knoten, die der Dienst enthält. Wenn die Aktivität erstellt wird (onResume usw.), müssen die OverlayItem-Objekte aus den Knotendaten neu erstellt werden, die der Dienst während der Abwesenheit der Aktivität verwaltet hat. Beispiel: Sie starten die App, der Dienst sammelt Daten, die Benutzeroberfläche zeigt sie an, Sie gehen zu Startseite und dann zurück zur App. Die Aktivität muss die OverlayItems aus den neuesten Dienstknotendaten abrufen und neu erstellen.

Ich weiß, dass dies keine guten oder klaren Fragen sind. Es ist, als ob alle meine SO-Fragen Nischen oder dunkel sind. Wenn jemand einen Vorschlag zur Interpretation dieser SIGSEGVFehler hat, wäre er sehr dankbar!

UPDATE Hier ist der letzte Absturz, der während einer Debug-Sitzung erfasst wurde. Ich habe 3 dieser Geräte, die zum Testen verwendet werden, und sie stürzen nicht alle zuverlässig ab, wenn ich entwickle und teste. Ich habe ein bisschen mehr hinzugefügt, damit die GC-Protokollierung notiert werden kann. Sie können sehen, dass das Problem wahrscheinlich nicht mit der Speichererschöpfung zusammenhängt.

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
Knoblauchmann
quelle
Fügen Sie weitere Informationen aus dem Protokoll zum Absturz hinzu.
Auselen
Ich habe einen Fehler wie diesen bereits behoben und würde erwarten, dass dies passiert, nachdem der Garbage Collector ausgeführt wurde. Sehen Sie das?
Paul Nikonowicz
32
Wie sind Sie von einer Zeile zu dieser riesigen Stapelspur gekommen? Ich bin mit der einzelnen Zeile festgefahren und kann nicht herausfinden, warum meine App abstürzt.
Sean Beach
endete damit, alle meine Objekte mit zu erweitern Java.Lang.Object. Sortierte meine Abstürze
Pierre
11
Um den gesamten Stack-Trace mit Adressreferenzen abzurufen, beenden Sie einfach das Filtern des Logcat nach Ihrem App-Prozess. Es wird direkt unter dem SIGSEGV-Fehler liegen.
Alexbchr

Antworten:

166

Holen Sie sich zunächst Ihren Tombstone-Stack-Trace, der bei jedem Absturz Ihrer App gedruckt wird. Etwas wie das:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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

Verwenden Sie dann das addr2lineDienstprogramm (finden Sie es in Ihrer NDK-Toolkette), um die abstürzende Funktion zu finden. In diesem Beispiel tun Sie dies

addr2line -e -f libc.so 0001173c

Und Sie werden sehen, woher Sie das Problem haben. Natürlich hilft dir das nicht, da es in libc ist.

Sie können also die Dienstprogramme von kombinieren arm-eabi-objdump, um das endgültige Ziel zu finden.

Glauben Sie mir, es ist eine schwierige Aufgabe.




Nur für ein Update. Ich glaube, ich habe lange Zeit ein natives Android-Build aus dem gesamten Quellbaum erstellt, bis heute habe ich die NDK-Dokumente sorgfältig gelesen. Seit der Veröffentlichung von NDK-r6 wird ein Dienstprogramm namens bereitgestellt ndk-stack.

Es folgt der Inhalt von offiziellen NDK-Dokumenten mit dem NDK-r9-Teerball.

Überblick:

ndk-stack ist ein einfaches Tool, mit dem Sie Stapelspuren filtern können, wie sie in der Ausgabe von 'adb logcat' angezeigt werden, und jede Adresse in einer gemeinsam genutzten Bibliothek durch die entsprechenden Werte ersetzen können.

Kurz gesagt, es wird etwas übersetzen wie:

  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):

In die besser lesbare Ausgabe:

  ********** 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

Verwendung:

Dazu benötigen Sie zunächst ein Verzeichnis mit symbolischen Versionen der gemeinsam genutzten Bibliotheken Ihrer Anwendung. Wenn Sie das NDK-Build-System (dh ndk-build) verwenden, befinden sich diese immer unter $ PROJECT_PATH / obj / local /, wo für den ABI Ihres Geräts steht (dh armeabistandardmäßig).

Sie können den logcatText entweder als direkte Eingabe in das Programm eingeben, z.

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

Oder Sie können die Option -dump verwenden, um den Logcat als Eingabedatei anzugeben, z.

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

WICHTIG:

Das Tool sucht in der logcatAusgabe nach der Anfangszeile mit den Starts , dh nach etwas, das wie folgt aussieht:

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

Vergessen Sie beim Kopieren / Einfügen von Traces diese Zeile aus den Traces ndk-stacknicht oder funktionieren nicht richtig.

MACHEN:

Eine zukünftige Version von ndk-stackwird versuchen adb logcat, den Bibliothekspfad automatisch zu starten und auszuwählen. Im Moment müssen Sie diese Schritte manuell ausführen.

Ab sofort ndk-stackbehandelt keine Bibliotheken , die Debug - Informationen nicht in ihnen. Es kann nützlich sein, zu versuchen, den nächstgelegenen Funktionseintrittspunkt zu einer bestimmten PC-Adresse zu ermitteln (z. B. wie im obigen Beispiel libc.so).

Robin
quelle
7
Entschuldigung Robin. Ich schätze die Antwort. Wenn ich meinen Crash-Dump gepostet hätte, was ich in einer anderen Frage speziell getan habe, hätten Sie möglicherweise im Kontext antworten können. Ich habe mich jedoch entschlossen, Ihnen die 100 Kopfgelder (meines wertvollen Vertreters!) Zu geben, da Sie der einzige waren, der versucht hat, die Aufgabe zu lösen, den Absturz auf die native Bibliotheksquelle zurückzuführen.
Knoblauchmann
1
Hallo Robin. Vielen Dank für eine detaillierte und informative Antwort. Ich habe mich gefragt, ob es möglich ist, die Informationen in den nativen Bibliotheken zu drucken. Meine nativen Bibliotheken haben viele Debugging-Informationen, mit denen ich gedruckt habe printf. Kann ich die Ausgabe davon printfaus den nativen Bibliotheken sehen.
Saad Saadi
#include <android / Log.h> #define LOGD (...) android_log_print (ANDROID_LOG_DEBUG, "YOURTAG", __ VA_ARGS )
Robin
Sie haben mir gerade Tage des Debuggens mit diesem Befehl ndk-stack erspart! Ich verstehe wirklich nicht,
Traian
Okay, ich habe den Absturzspeicherauszug gedruckt, verstehe aber die Ausgabe immer noch nicht.
Hilal
48

OK! Es tut mir wirklich leid für diejenigen, die tatsächlich Kommentare und Antworten eingereicht haben, aber ich habe das Problem gefunden. Ich denke nicht, dass dies vielen anderen helfen wird, ihre persönliche SIGSEGV aufzuspüren, aber meine (und es war sehr schwer) war völlig damit verbunden:

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

Die libcrypto.so in meinem Dump hat mich irgendwie darauf hingewiesen. Ich mache einen MD5-Hash von Paketdaten, wenn ich versuche festzustellen, ob ich das Paket bereits gesehen habe, und überspringe es, wenn ich es hatte. Ich dachte irgendwann, dies sei ein hässliches Threading-Problem im Zusammenhang mit der Verfolgung dieser Hashes, aber es stellte sich heraus, dass es sich um die Klasse java.security.MessageDigest handelte! Es ist nicht threadsicher!

Ich habe es mit einer UID ausgetauscht, die ich in jedes Paket gestopft habe, basierend auf der UUID des Geräts und einem Zeitstempel. Keine Probleme seitdem.

Ich denke, die Lektion, die ich denjenigen erteilen kann, die sich in meiner Situation befanden, besteht darin, auch wenn Sie eine 100% ige Java-Anwendung sind, auf die native Bibliothek und das Symbol zu achten, die im Absturzspeicherauszug für Hinweise angegeben sind. Wenn Sie nach SIGSEGV + googeln, geht der Name lib .so viel weiter als der nutzlose Code = 1 usw. Überlegen Sie sich als Nächstes, wo Ihre Java-App nativen Code berühren könnte, auch wenn Sie nichts tun. Ich habe den Fehler gemacht, anzunehmen, dass es sich um ein Service + UI-Threading-Problem handelt, bei dem der Canvas etwas gezeichnet hat, das null ist (der häufigste Fall, in dem ich auf SIGSEGV gegoogelt habe), und habe die Möglichkeit ignoriert, dass es vollständig mit dem von mir geschriebenen Code zusammenhängt bezogen auf die lib .so im Absturzspeicherauszug. Natürlich würde java.security aus Gründen der Geschwindigkeit eine native Komponente in libcrypto.so verwenden. Sobald ich mich darauf eingelassen hatte, googelte ich nach Android + SIGSEGV + libcrypto. so und fand das dokumentierte Problem. Viel Glück!

Knoblauchmann
quelle
1
Habe ein ähnliches Problem, immer noch mit MessageDigest, ok, überhaupt nicht threadsicher. Anstelle einer schönen Ausnahme bekommen wir einen hässlichen Absturz!
Bamaco
Ähnliches hatte ich mit der RSA-Entschlüsselung mit Openssl. Das Verschieben des Vorgangs in einen neuen Thread hat das Problem behoben.
Peceps
41

Ich habe diesen Fehler erhalten, indem ich ein Objekt in den freigegebenen Einstellungen als gson-konvertierte Zeichenfolge gespeichert habe. Der gson-String war nicht gut, daher funktionierte das Abrufen und Deserialisieren des Objekts nicht richtig. Dies bedeutete, dass alle nachfolgenden Zugriffe auf das Objekt zu diesem Fehler führten. Unheimlich :)

Daniel Wilson
quelle
6
Danke, das hat mir gerade das Leben gerettet :))) Sie erhalten dies, wenn das Objekt, das gson zu konvertieren versucht, keinen gültigen Konstruktor hat (ich habe es mit der android.Location-Klasse versucht und diesen Fehler
ausgegeben
5
@rosualin Oh mein Gott! Dies kann genau mein Problem sein (hier meine Haare herausziehen). Ich speichere das android.LocationObjekt auch SharedPreferencesin einem WakefulBroadcastReceiver. Meistens funktioniert es, aber manchmal bekomme ich den gefürchteten SIGSEGVAbsturz. Können Sie uns bitte mitteilen, wie Sie es gelöst haben?
CamelCaseCoder
3
Nun, ich habe versucht, android.Location oder Geofence in gemeinsamen Einstellungen zu speichern, und ohne Konstruktor würde dies dazu führen. Also habe ich eine benutzerdefinierte Klasse mit den benötigten Daten erstellt und diese einfach gespeichert. Ich hoffe es hilft.
Rosu Alin
3
@rosualin Es hat funktioniert !!!!!!!!!!! Du bist ein Lebensretter!!! Ich war in den letzten 4 Tagen verrückt nach diesem dummen Käfer. Ich danke dir sehr!!!!
CamelCaseCoder
1
Ich bin froh, dass ich helfen konnte: D
Rosu Alin
30

Ich habe diesen Fehler auch oft bekommen und ihn gelöst. Dieser Fehler tritt bei der Speicherverwaltung auf der nativen Seite auf.

Ihre Anwendung greift auf Speicher außerhalb ihres Adressraums zu. Dies ist höchstwahrscheinlich ein ungültiger Zeigerzugriff. SIGSEGV = Segmentierungsfehler im nativen Code. Da es in Java-Code nicht vorkommt, wird kein Stack-Trace mit Details angezeigt. Möglicherweise werden jedoch noch einige Stapelverfolgungsinformationen im Protokoll angezeigt, wenn Sie sich nach dem Absturz des Anwendungsprozesses ein wenig umschauen. Sie erfahren nicht die Zeilennummer in der Datei, sondern, welche Objektdateien und Adressen in der Aufrufkette verwendet wurden. Von dort aus können Sie häufig herausfinden, welcher Bereich des Codes problematisch ist. Sie können auch eine native GDB-Verbindung zum Zielprozess einrichten und diese im Debugger abfangen.

Vivek Bansal
quelle
In meinem Fall war die zugrunde liegende Komponente von java.security.MessageDigest nicht threadsicher und ich habe über zwei Threads darauf zugegriffen. (Erstellen Sie den Hash und speichern Sie, dann erstellen Sie den Hash und vergleichen Sie)
Knoblauchman
Sie erhalten diese schwerwiegende Ausnahme aufgrund von java.security, MessageDigest oder einem anderen Thread nicht. Möglicherweise ist dies nicht der genaue Ort, an dem der Speicher beschädigt wird. Wenn Sie beispielsweise den Heap beschädigen, kann eine beliebige Anzahl von Operationen später ausgeführt werden, und es kann durchaus sein, dass er sich außerhalb des NDK-Speicherplatzes befindet. Sie werden es erst am Ende der Funktion wissen.
Vivek Bansal
Nehmen wir nur an, wenn Ihr Code in Zeile 10 auf der nativen Seite bricht, läuft Ihr Code auch danach einwandfrei und nach dem Ausführen einiger Codezeilen wird dieser Fehler im Java-Teil ausgegeben. Es passiert. "Java löst Ausnahmen aus, wenn Sie sich außerhalb des Speichers bewegen". Ja, zum Glück, aber nur um zu verdeutlichen, dass die App abstürzen kann, ohne dass eine Standard-Java-Ausnahme ausgelöst wird, wenn er den Speicher in C / C ++ überschreitet und auf Java übergeht. Deshalb kommt es zu tödlichen Folgen.
Vivek Bansal
Versuchen Sie, Fehler auf der nativen Seite herauszufinden, auf der Sie ein beliebiges Datenarray verwendet haben. In den meisten Fällen tritt dies in Datenarrays auf, wenn Sie versehentlich die Grenzen oder das Datenlimit überschreiten.
Vivek Bansal
24

Heute stand ich vor einem Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161Problem und ich kämpfe einen halben Tag, um dieses zu lösen.

Ich habe viele Dinge versucht, um den Cache zu leeren und die .gradle-Datei und alles zu löschen.

Endlich bekomme ich disable Instant Runund jetzt dieses Problem nicht mehr. Jetzt funktioniert meine Anwendung, nachdem auch die sofortige Ausführung aktiviert wurde. Möglicherweise handelt es sich um das Sofortlaufproblem. Versuchen Sie, den Sofortlauf zu deaktivieren und zu aktivieren

Aus dieser Antwort:

Gehen Sie zu Android Studio-Einstellungen oder -Einstellungen (für MAC) -> Erstellen, Ausführen, Bereitstellen -> Sofortige Ausführung.

Deaktivieren Sie dann oben das Kontrollkästchen "Sofortige Ausführung aktivieren".

Naveen Kumar M.
quelle
1
Ich habe einen halben Tag damit verbracht, diesen nicht vorhandenen Fehler zu finden, bis ich Ihre Lösung gefunden habe. Vielen Dank, Mann!
Kanat
1
Gleiches Problem für mich nach dem Upgrade auf AndroidX. Ich muss sofort weglaufen lassen.
JamesD
abhaken, aber Signal 11 (SIGSEGV), Code 2 (SEGV_ACCERR)
Chego
Hallo, ich benutze Android Studio 3.5.1 und ich hatte fast einen Tag versucht, es zu beheben, aber ich habe immer noch das gleiche Problem, ich habe eine Google Map in Fragment und es funktioniert nur beim ersten Mal, wenn ich die App danach jedes Mal installiert habe, wenn ich Öffnen Sie die App und geben Sie mir ein schwerwiegendes Signal 11 (SIGSEGV), Code 1, Fehleradresse 0xff3a200c in tid 15323 (FinalizerDaemon)
Navin
Bei Android Studio 3.5 und höher müssen Sie die Option "Änderungen übernehmen" verwenden. Versuchen Sie, diese Option zu aktivieren und zu deaktivieren. Es hat bei mir funktioniert.
Aanal Mehta
12

Deaktivieren Sie die Android-Hardwarebeschleunigung in Ihrem Manifest.

android:hardwareAccelerated="false"
BYISHIMO Audace
quelle
2
es funktioniert aber überhaupt keine gute lösung !! stoppt alle Animationen und grafischen Dinge
Mohsen
Ich habe das gleiche Problem, aber von meiner Seite nicht funktioniert, ich habe Google Map in Fragment verwendet und als ich die Anwendung öffnete, stürzte es ab. Tödliches Signal 11 (SIGSEGV), Code 1, Fehleradresse 0x3f000000 in tid 16591 (FinalizerDaemon), das ich versucht habe fast einen Tag, aber nicht die richtige Lösung dafür gefunden, es funktioniert nur wenige Male, dann gibt es einen Fehler
Navin
11

Ich habe diesen Fehler festgestellt, als ich versucht habe, auf die 'Zeichenfläche' außerhalb von zuzugreifen 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

Eine sehr schlechte Praxis: /

Prabs
quelle
5

Ich habe diesen Fehler erhalten, als ich eine Bitmap wie diese verwendet habe:

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

Was das Problem für mich behoben hat, war die Verkleinerung der Bitmap (> 1000px hoch auf 700px).

David Walton
quelle
Verwenden Sie stattdessenBitmapOptions.inSampleSize
FindOut_Quran
4

Ich habe mit SIGSEGV auf Android 4.4.4 (Nexuses, Samsungs) konfrontiert. Es stellte sich heraus, dass beim Parsen null Stringmit ein schwerwiegender Fehler aufgetreten istDecimalFormat

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

Unter Android> 21 wurde es erfolgreich mit try / catch behandelt

Yazazzello
quelle
3

Ich konfrontiert dieses Problem Moment vor, nachdem er von der Migration android.supportzu androidx.

Das Problem war renderscript .

Lösung: Ich habe build.gradlediese beiden Zeilen entfernt:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

nachdem dieser Projektaufbau aufgrund ungelöster Referenzen fehlgeschlagen ist:

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

Also habe ich sie geändert in:

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

Danach waren alle Probleme weg.

Cililing
quelle
2

Wenn Sie die Vitamio-Bibliothek verwenden und dieser schwerwiegende Fehler auftritt.

Stellen Sie dann sicher, dass in Ihrem Projekt gradle targetSdkVersion kleiner als 23 sein muss.

Vielen Dank.

mehmoodnisar125
quelle
Ihre Lösung funktioniert, dies könnte jedoch ein großes Problem sein, da der Play Store obligatorisch ist, um targetSdkversion ab dem 1. August auf> = 26 zu setzen.
Shishir Shetty
2

In meinem Fall (ich verwende Xamarin Forms) wurde dieser Fehler aufgrund eines Bindungsfehlers ausgelöst - z. B.:

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

Grundsätzlich habe ich versehentlich die Ansichtsmodelleigenschaft gelöscht. Wenn Sie bei Xamarin-Entwicklern das gleiche Problem haben, überprüfen Sie Ihre Bindungen ...

Dragos Stoica
quelle
2

Wenn Sie Ihrem Projekt nativen C-Code hinzugefügt haben, kann diese Antwort hilfreich sein.

Ich hatte einige native C-Code in Android-Projekt hinzugefügt.

Jetzt habe ich versucht, auf den Code zuzugreifen, der mir eine native Zeichenfolge zurückgab, bevor ich die Zeichenfolge verarbeitete, deren Standardwert ich als nullptr festgelegt hatte. Beim Abrufen des Werts in Java-Code ist dieses Problem aufgetreten.

Da unser nativer C-Code nicht aus dem Java-Verzeichnis stammt, erhalten Sie keinen Hinweis auf die genaue Codezeile, die das Problem verursacht. Daher würde ich Ihnen empfehlen, Ihre CPP-Datei zu überprüfen und dort nach Hinweisen zu suchen.

Ich hoffe, Sie werden das Problem bald beseitigen. :) :)

Ali Nawaz
quelle
1

In meinem Fall wurde das Problem vom Android Profiler verursacht. Klicken Sie in Android Studio auf "Android Profiler" und "Sitzung beenden".

Ironischerweise verursachte es auch extreme Leistungsprobleme in der Anwendung.

Tomacco
quelle
1

Fügen Sie diese beiden Zeilen zu Ihrem build.gradle im Android-Bereich hinzu:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}
M. Chithirai Perumal
quelle
5
Während dieser Code eine Lösung für die Frage bietet, ist es besser, einen Kontext hinzuzufügen, warum / wie er funktioniert. Dies kann zukünftigen Benutzern helfen, zu lernen und dieses Wissen auf ihren eigenen Code anzuwenden. Es ist auch wahrscheinlich, dass Sie positive Rückmeldungen von Benutzern in Form von Upvotes erhalten, wenn der Code erklärt wird.
Borchvm
0

Überprüfen Sie Ihren JNI / nativen Code. Eine meiner Referenzen war null, aber sie war zeitweise, so dass es nicht sehr offensichtlich war.

zMan
quelle
0

Überprüfen Sie Ihre nativen Funktionen, ob sie ordnungsgemäß zurückgegeben werden oder nicht. Wenn sie nicht zurückgegeben werden, fügen Sie bitte return-Anweisungen hinzu.

Jeyanth
quelle
0

Für mich war dieses Problem auf eine schlechte Besetzung zwischen zwei Aktivitäten zurückzuführen. Ich habe diese Methode kürzlich von Aktivität1 auf eine andere 2 verschoben. Dabei hat der Refactor diese explizite Besetzung wie zuvor belassen. Also anstatt zu tun

((Activity1) mainActivity).hideDialog();

Ich sollte es tun

((Activity2) mainActivity).hideDialog();

Hinweis: Aber dieser Fehler ist unter Android 8.0 nicht aufgetreten. Ich bin mir noch nicht sicher, warum.

*** Ich hoffe es hilft.

Gomez NL
quelle
0

Ich hatte diesen Segmentierungsfehler aufgrund von Speicherproblemen . Meine Struktur mit vielen Variablen und Arrays hatte dieses Array der Größe 1024.

Beim Reduzieren der Größe auf 512 war der Fehler behoben.

PS: Dies ist eine Problemumgehung und keine Lösung. Es ist notwendig, die Strukturgröße zu finden, und die dynamische Speicherzuordnung ist eine bessere Option.

Shachi
quelle
Ich habe das gleiche Problem, aber es funktioniert umgekehrt. Ich speichere bis zu 492 Daten in meinem Array. Wenn ich die Größe auf 512 einstelle, wird der Segfault-Fehler angezeigt und meine App geschlossen. Wenn ich die Größe auf 1024 erhöhe, wird sie nicht angezeigt. Ich habe Probleme zu verstehen, wie das funktioniert.
8.
0

Ich habe diesen Fehler erhalten, als ich ViewTreeObserver inside onDraw()verwendet habe.

@Override
protected void onDraw(Canvas canvas) {
    // super.onDraw(canvas);
    ViewTreeObserver vto = mTextView.getViewTreeObserver();
    vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // some animation        
        }
    });
 }
Muzamil
quelle
Ich habe es gelöst, indem ich ViewTreeObserver von onDraw entfernt habe
muzamil
0

Ich hatte dieses Problem mit einem Paket, das meiner App hinzugefügt wurde (FancyShowCaseView) und dieses Problem auf Pre-Lolipop verursacht hat. Dieses Paket wurde in Kotlin geschrieben und meine Hauptcodes wurden in Java geschrieben. Jetzt überprüfe ich die Version in Pre-Lolipop und lasse nicht zu, dass ihre Klasse ausgeführt wird. vorübergehend das Problem gelöst. Überprüfen Sie dies, wenn Sie ein ähnliches Problem wie ich haben

Hossein Karami
quelle
0

Fingerabdruck erstellen: 'motorola / harpia / harpia: 6.0.1 / MPIS24.241-2.50-16 / 16: Benutzer- / Release-Schlüssel' Revision: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, Name: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< Signal 11 (SIGSEGV), Code 2 (SEGV_ACCERR), Fehleradresse 0x7452f000

2 von 12 Telefonen haben einen Fehler zurückgegeben und festgestellt, dass das Problem in onDrawFrame () liegt. Einige Objekte waren null. Ich weiß nicht warum. Ich habe sie nur festgelegt

if(gears==null) return;.

Chego
quelle
0

Ich hatte das Problem, als ich ein PDF mit den PDF-APIs von Android erstellte, und habe versehentlich die Zeichenfläche canvas.save () und canvas.restore () verwendet, nachdem ich eine PDF-Seite geschlossen hatte.

Abdollah Ebadi
quelle