Android致命信号11（SIGSEGV）位于0x636f7d89（代码= 1）。如何找到它？

221

我一直在阅读其他文章，以追踪SIGSEGV在Android应用程序中获取的原因。我计划在我的应用程序中搜索与Canvas使用相关的可能的NullPointers，但我SIGSEGV每次都会使用不同的内存地址。另外我看过code=1和code=2。如果内存地址是0x00000000，那么我就知道它是NullPointer。

我得到的最后一个是code=2：

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

关于如何追踪这个的任何建议？

我有一个嫌疑犯，但是我还不愿意尝试它。我的应用程序使用OSMDroid API进行离线映射。OverlayItem类表示地图上的标记/节点。我有一个服务，可通过网络收集数据以填充OverlayItem，然后将其显示在地图上。为了简化设计，我将OverlayItem扩展到我自己的NodeOverlayItem类中，该类包括我在UI Activity和Service中使用的一些附加属性。这给了我关于UI和服务的单点信息。当发生更改时，我使用Intents广播到Activity来刷新UI映射。活动绑定到服务，并且有一个Service方法来获取NodeOverlayItem的列表。我认为这可能是OSMDroid API对OverlayItem的使用，和我的服务同时更新节点信息。（并发问题）

在我撰写本文时，我认为这确实是问题所在。令人头疼的不是将Node和OverlayItem从NodeOverlayItem中分离出来，而是因为Activity需要来自Node的一些数据，而该数据是服务所拥有的。另外，当创建活动（onResume等）时，需要根据活动不在时服务一直在维护的Node数据重新创建OverlayItem对象。例如，您启动应用程序，服务会收集数据，UI会显示它，您转到首页，然后回到应用程序，活动将需要从最新的服务节点数据中提取并重新创建OverlayItem。

我知道这不是一个很好的或明确的问题。就像我所有的SO问题都是利基或晦涩的。如果有人对如何解释这些SIGSEGV错误有任何建议，将不胜感激！

更新这是在调试会话期间捕获的最新崩溃。我有3个这样的设备用于测试，在我进行开发和测试时，它们并不会全部崩溃。我添加了一些额外内容，以便可以记录GC日志记录。您可以看到该问题可能与内存耗尽无关。

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

— 大蒜人
source

从日志中添加有关崩溃的更多信息。

— 2013年

我之前已经修复了这样的错误，并且希望在运行垃圾收集器后会看到这种情况。那是你看到的吗？

— Paul Nikonowicz 2013年

32

您是如何从一条线转到那条巨大的堆栈轨迹的？我只停留在一行，无法弄清楚为什么我的应用程序崩溃了。

— 肖恩海滩

最终用扩展了我的所有对象Java.Lang.Object。整理出我的crashings

— 皮埃尔·

11

为了获得带有地址引用的整个堆栈跟踪，只需停止通过您的应用进程过滤logcat。它将低于SIGSEGV错误。

— alexbchr

166

首先，获取您的逻辑删除堆栈跟踪，它将在您的应用程序每次崩溃时打印。像这样：

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

然后，使用该addr2line实用程序（在NDK工具链中找到它）来查找崩溃的功能。在此示例中，

addr2line -e -f libc.so 0001173c

您将看到问题出在哪里。当然，因为它在libc中，所以对您没有帮助。

因此，您可以结合使用的实用程序arm-eabi-objdump来找到最终目标。

相信我，这是一项艰巨的任务。

只是为了更新。我想我已经从整个源代码树开始进行Android本机构建很长时间了，直到今天我已经仔细阅读了NDK文档。自NDK-r6版本发布以来，它提供了一个名为的实用程序ndk-stack。

以下是带有NDK-r9 tar球的NDK官方文档的内容。

概述：

ndk-stack 是一个简单的工具，可让您过滤堆栈跟踪，使其显示在“ adb logcat”的输出中，并将共享库中的任何地址替换为相应的：值。

简而言之，它将转换为：

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

进入更具可读性的输出：

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

用法：

为此，您首先需要一个目录，其中包含应用程序共享库的符号版本。如果您使用NDK构建系统（例如ndk-build），则它们始终位于$ PROJECT_PATH / obj / local /下，代表设备的ABI（即armeabi默认情况下）。

您可以将logcat文本作为程序的直接输入，例如：

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

或者，您可以使用-dump选项将logcat指定为输入文件，例如：

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

重要事项：

该工具在logcat输出中查找包含开始的初始行，即如下所示：

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

复制/粘贴跟踪时，请不要忘记跟踪中的这一行，否则ndk-stack将无法正常工作。

去做：

的未来版本ndk-stack将尝试启动adb logcat并自动选择库路径。现在，您必须手动执行这些步骤。

到目前为止，ndk-stack不处理其中没有调试信息的库。尝试检测到给定PC地址最近的函数入口点可能很有用（例如，如上面的libc.so示例中所示）。

— 罗宾
source

7

抱歉，罗宾。我很感谢答案。如果我已经发布了崩溃转储，而这是我在另一个有关它的问题中所做的，那么您也许可以在上下文中回答。但是我决定给您100英镑的奖金（我的宝贵功劳！），因为您是唯一尝试解决将崩溃回溯到本机库源代码的任务的任何地方。

— 蒜人

1

你好罗宾。非常感谢您提供详尽而翔实的答案。我在想，是否可以在本机库中打印信息。我的本机库中有很多调试信息，这些信息是我使用打印的printf。我可以printf从本地库中看到输出吗？

— 萨阿迪·萨阿迪

#include <android / Log.h> #define LOGD（...） android_log_print（ANDROID_LOG_DEBUG，“ YOURTAG”，__ VA_ARGS）

— 罗宾

您刚刚使用该ndk-stack命令节省了我很多天的调试时间！我真的不明白我怎么没找到它……

— Traian

好的，我已经打印了故障转储，但是仍然不了解输出。

— 希拉尔

48

好！对于真正提交评论和答案的人，我感到非常抱歉，但我发现了问题。我认为这不会帮助其他许多试图追踪其个人SIGSEGV的人，但是我的（这非常困难）与以下内容完全相关：

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

我的转储中的libcrypto.so使我陷入困境。当尝试确定是否已经看到数据包时，我对数据包数据进行MD5哈希处理，如果有，则跳过该数据包。我以为这是与跟踪这些哈希值相关的丑陋线程问题，但事实证明它是java.security.MessageDigest类！它不是线程安全的！

我换了一个UID，我根据设备UUID和时间戳将每个数据包塞进了每个数据包中。此后没有问题。

我猜想，即使您是100％Java应用程序，也可以从我遇到的情况中学到的教训，请注意崩溃转储中记录的本机库和符号以获取线索。搜寻SIGSEGV + lib .so名称会比无用的代码= 1等等要远得多，等等...接下来考虑一下您的Java应用程序可以在哪里接触本机代码，即使您什么也没做。我犯了一个错误，即它是一个Service + UI线程问题，其中Canvas绘制的是空的东西（这是我在SIGSEGV上搜索的最常见情况），而忽略了它可能与我编写的代码完全相关的可能性。与崩溃转储中的lib .so有关。自然，java.security会使用libcrypto.so中的本机组件来提高速度，因此一旦进入，我就用Google + Android + SIGSEGV + libcrypto搜索了。如此，发现了记录的问题。祝好运！

— 大蒜人
source

1

还有一个类似的问题，仍然是MessageDigest，好吧，根本不是线程安全的。而不是一个很好的例外，我们得到了一个丑陋的崩溃！

— 巴马科

我使用Openssl对RSA解密也有类似的事情。在新线程中移动操作解决了该问题。

— pepseps

41

我通过将对象保存为gson转换后的字符串到共享首选项中而遇到此错误。gson String不好，因此检索和反序列化该对象实际上无法正常工作。这意味着对该对象的任何后续访问都将导致此错误。害怕：）

— 丹尼尔·威尔逊
source

6

谢谢，这只是挽救了我的生命:)））如果gson尝试转换的对象没有有效的构造函数（我在android.Location类中尝试过，给出了此错误），您将得到此消息

— rosu alin

5

@rosualin噢，天哪！这可能正是我的问题（在这里拔头发）。我也将android.Location对象存储在SharedPreferences中WakefulBroadcastReceiver。在大多数情况下，它都能正常工作，但有时我会遇到可怕的SIGSEGV崩溃。您能分享您如何解决吗？

— camelCaseCoder

3

好吧，我试图将android.Location或Geofence保存在共享首选项中，并且没有构造函数，这会导致这种情况。因此，我使用所需的数据做了一个自定义类，并保存了该数据。希望能帮助到你。

— rosu alin 2015年

3

@rosualin有效!!!!!!!!!!!!! 您是救生员！！！在过去的4天里，我一直在为这个愚蠢的错误而疯狂。非常感谢！！！！

— camelCaseCoder

1

很高兴我可以帮助您：D

— 罗苏·阿林

30

我也多次遇到此错误，并已解决。如果在本机端进行内存管理，将遇到此错误。

您的应用程序正在访问其地址空间之外的内存。这很可能是无效的指针访问。SIGSEGV =本机代码中的分段错误。由于它不是在Java代码中发生的，因此您不会看到包含详细信息的堆栈跟踪。但是，如果在应用程序崩溃后四处看看，您可能仍会在logcat中看到一些堆栈跟踪信息。它不会告诉您文件中的行号，但是会告诉您在调用链中使用了哪些目标文件和地址。从那里您通常可以找出代码的哪个区域有问题。您还可以设置与目标进程的gdb本机连接，并将其捕获到调试器中。

— Vivek Bansal
source

就我而言，那是java.security.MessageDigest的底层组件不是线程安全的，我是从2个线程访问它的。（创建散列并存储，然后创建散列并进行比较）

— 大蒜人

由于java.security，MessageDigest或任何线程，您没有收到此致命异常。它可能不是内存损坏的确切位置。例如，如果您破坏了堆，则以后可能会进行任何数量的操作，并且很可能在NDK空间之外。在函数结束之前您不会知道。

— Vivek Bansal 2013年

只是假设如果您的代码在本机端在第10行中断，那么即使在此之后，您的代码也将运行良好，并且在执行了几行代码之后，它将在Java部分中引发此错误。它发生了。“当您移出内存时，Java将引发异常”。是的，幸运的是，但是只是为了澄清一下，如果他超出了C / C ++的内存并且将其转移到Java，则该应用程序可能崩溃而不会引发标准Java异常。这就是为什么会发生致命的蛋白质分泌的原因。

— Vivek Bansal 2013年

尝试在使用任何数据数组的本机端找出错误。在大多数情况下，这会在数据数组中发生，这是当您错误地越过其界限或数据限制时。

— Vivek Bansal 2013年

24

今天，我遇到了Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161问题，半天都无法解决。

我尝试了许多清除缓存和删除.gradle文件的方法。

最后，我disable Instant Run现在不再遇到这个问题。现在，我的应用程序在启用即时运行之后也可以运行。可能是即时运行问题，请尝试禁用和启用即时运行

从这个答案：

转到Android Studio设置或首选项（对于MAC）->构建，执行，部署->即时运行。

然后取消选中顶部的“启用即时运行”复选框。

— Naveen Kumar M
source

1

我花了半天的时间来查找不存在的错误，直到找到您的解决方案为止。非常感谢，伙计！

— 卡纳特

1

升级到androidx后，对我来说同样的问题。我必须立即离开。

— JamesD

检查，但信号11（SIGSEGV），代码2（SEGV_ACCERR）

— Chego，

您好我正在使用android studio 3.5.1，我已经尝试了将近一天的时间来修复它，但是仍然有相同的问题，我在片段中使用了Google地图，并且每次当我安装应用后第一次安装它时，它才第一次工作打开应用程序，它会给我以下致命信号11（SIGSEGV），代码1，在tid 15323（FinalizerDaemon）中出现故障加法器0xff3a200c

— Navin

对于Android Studio 3.5及更高版本，您需要使用选项“应用更改”。尝试启用和禁用此选项。它为我工作。

— Aanal Mehta

12

尝试在清单中禁用Android硬件加速。

android:hardwareAccelerated="false"

— BYISHIMO奥德赛
source

2

它有效，但根本不是一个好的解决方案！停止所有动画和图形处理

— Mohsen

我有相同的问题，但从我这一边无法正常工作，我在片段中使用了谷歌地图，当我打开应用程序时，它崩溃了，提示16591（FinalizerDaemon）中的致命信号11（SIGSEGV），代码1，错误地址0x3f000000将近一天，但没有找到正确的解决方案，它只能工作几次，然后给出一个错误

— Navin

11

当我尝试访问外部的“画布”时遇到了此错误 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

一个非常糟糕的做法：/

— Prabs
source

5

使用如下位图时出现此错误：

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

对我来说，解决此问题的方法是减小位图的大小（从1000像素高到700像素）。

— 大卫·沃尔顿
source

请改用BitmapOptions.inSampleSize

— FindOut_Quran 2015年

4

我在Android 4.4.4（Nexus，Samsungs）上遇到过SIGSEGV，结果发现致命错误是null String使用DecimalFormat

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

在Android> 21上，已通过try / catch成功处理

— 亚扎泽洛
source

3

从迁移android.support到以后，我刚才遇到了这个问题androidx。

问题是renderscript。

解决方案：我从build.gradle这两行中删除了：

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

在该项目构建失败后，由于未解决的引用：

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

所以我将它们更改为：

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

之后，所有问题都消失了。

— ili
source

2

如果您使用的是vitamio库，则会发生此致命错误。

然后确保在您的项目中，gradle targetSdkVersion必须小于23。

谢谢。

— 第125章
source

您的解决方案有效，但这可能是一个主要问题，因为Play商店强制要求将targetSdkversion设置为8月1日起> = 26。

— Shishir Shetty

2

就我而言（我正在使用Xamarin Forms），由于绑定错误而引发了此错误-例如：

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

基本上，我错误地删除了视图模型属性。对于Xamarin开发人员，如果您遇到相同的问题，请检查绑定...

— 德拉戈斯·斯托卡
source

2

如果您在项目中添加了一些本机C代码，则此答案可能会有所帮助。

我在android项目中添加了一些本机C代码。

现在，我在处理将字符串的默认值设置为nullptr之前，尝试访问返回本机字符串的代码。现在，在Java代码中检索其值时遇到了此问题。

由于我们的本机C代码不在java目录中，因此不了解导致问题的确切代码行。因此，我建议您检查.cpp文件并尝试在其中找到任何线索。

希望您能尽快解决此问题。:)

— 阿里·纳瓦兹（Ali Nawaz）
source

1

就我而言，问题是由Android Profiler引起的。在Android Studio中，单击“ Android Profiler”和“结束会话”。

具有讽刺意味的是，这也导致了应用程序中的极端性能问题。

— 托马克
source

1

将这两行添加到android部分的build.gradle中：

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

— 基希拉伊·佩鲁马尔
source

5

尽管此代码可以为问题提供解决方案，但最好添加有关其原因/工作方式的上下文。这可以帮助将来的用户学习并将该知识应用于他们自己的代码。在解释代码时，您还可能以投票的形式从用户那里获得正面的反馈。

— borchvm

0

检查您的JNI /本机代码。我的参考文献之一为空，但它是断断续续的，因此不是很明显。

— Man
source

0

检查您的本机函数，是否返回正确，如果未返回，请添加return语句。

— 杰扬斯
source

0

对我来说，这个问题是由于两项活动之间的表现不佳。我最近将此方法从Activity1移到了另一个2。这样做，重构使此显式转换保持了以前的状态。所以不要做

((Activity1) mainActivity).hideDialog();

我应该做的

((Activity2) mainActivity).hideDialog();

注意：但是这个错误在android 8.0上没有发生，我不确定为什么。

*** 希望能帮助到你。

— 戈麦斯NL
source

0

由于内存问题，我遇到了此分段错误错误。我的结构具有许多变量和数组，该数组的大小为1024。

将大小减小到512，该错误消失了。

PS：这是一种解决方法，而不是解决方案。有必要找到结构大小，动态内存分配 是一个更好的选择。

— 沙池
source

我遇到了同样的问题，但是相反。我在阵列中最多存储492个数据。如果我将大小设置为512，则会出现segfault错误并关闭我的应用程序，当我将大小增加至1024时，它不会出现。我无法理解其工作原理。

— 体重

0

在onDraw()函数内部使用ViewTreeObserver时出现此错误。

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

— 穆扎米尔
source

我通过从onDraw中删除ViewTreeObserver来解决了问题

— -muzamil

0

我在添加到我的应用程序（FancyShowCaseView）的程序包中遇到了这个问题，并在lolipop之前引起了这个问题。该软件包是用kotlin编写的，而我的主要代码是用java编写的。所以现在我要检查pre-lolipop中的版本，不要执行其类。暂时解决了问题。如果您有类似我的问题，请查看此

— 侯赛因·卡拉米（Hossein Karami）
source

0

构建指纹：'motorola / harpia / harpia：6.0.1 / MPIS24.241-2.50-16 / 16：user / release-keys'修订版：'p1b0'ABI：'arm'pid：18139，tid：25935，name： GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<<信号11（SIGSEGV），代码2（SEGV_ACCERR），故障加法器0x7452f000

12部手机中有2部返回错误，发现问题出在onDrawFrame（）中，某些对象为null，我不知道为什么，我只设置了

if(gears==null) return;。

— go
source

0

我在使用Android的PDF API创建PDF时遇到了问题，并且在关闭pdf页面后不小心使用了canvas.save（）和canvas.restore（）。

— 阿卜杜拉·埃巴迪
source