285

我一直在阅读其他关于追踪SIGSEGV在 Android 应用程序中获得 a 的原因的帖子。我计划在我的应用程序中搜索与 Canvas 使用相关的可能 NullPointers,但我SIGSEGV每次都会搜索不同的内存地址。加上我见过code=1code=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 地图。Activity 绑定到 Service,并且有一个 Service 方法来获取 NodeOverlayItem 的列表。我认为这可能是 OSMDroid API 对 OverlayItem 的使用,和我的服务同时更新节点信息。(并发问题)

在我写这篇文章时,我认为这确实是问题所在。令人头疼的不是从 NodeOverlayItem 中分离出 Node 和 OverlayItem,而是 Activity 需要来自 Node 的一些数据,这些数据由 Service 持有。另外,当创建 Activity(onResume 等)时,需要根据服务在 Activity 离开时一直维护的节点数据重新创建 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
4

28 回答 28

183

首先,获取你的墓碑堆栈跟踪,每次你的应用程序崩溃时都会打印它。像这样的东西:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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 示例中)。

于 2013-08-29T09:36:41.360 回答
61

我发现了问题。我认为这不会帮助很多其他人试图追踪他们的个人 SIGSEGV,但我的(而且非常困难)与此完全相关:

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

我转储中的 libcrypto.so 有点提示我。当我尝试确定我是否已经看到数据包时,我对数据包数据进行 MD5 散列,如果有则跳过它。我一度认为这是一个与跟踪这些哈希相关的丑陋线程问题,但结果证明这是 java.security.MessageDigest 类!这不是线程安全的!

我根据设备 UUID 和时间戳将其替换为填充在每个数据包中的 UID。从此没有问题。

我想我可以向那些处于我这种情况的人传授的教训是,即使您是 100% Java 应用程序,也要注意故障转储中记录的本机库和符号以获取线索。谷歌搜索 SIGSEGV + lib .so 名称将比无用的代码 = 1 等走得更远……接下来想想你的 Java 应用程序可以在哪里接触本机代码,即使你什么都没做。我错误地假设它是一个服务 + UI 线程问题,其中 Canvas 正在绘制一些为空的东西(我在 SIGSEGV 上搜索的最常见的情况)并且忽略了它可能与我编写的代码完全相关的可能性是与故障转储中的 lib .so 相关。自然地,java.security 会使用 libcrypto.so 中的本机组件来提高速度,所以一旦我找到线索,我就在 Google 上搜索了 Android + SIGSEGV + libcrypto。

于 2013-09-05T21:01:28.440 回答
51

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

于 2015-08-06T22:28:40.917 回答
31

我也多次遇到这个错误,我解决了。如果在本机端进行内存管理,将面临此错误。

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

于 2013-09-11T12:23:40.470 回答
28

今天我遇到Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161了问题,我挣扎了半天来解决这个问题。

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

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

这个答案:

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

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

于 2018-05-31T10:56:01.437 回答
25

对我来说,在 Android Studio 4.1 上,诀窍是 ole File > Invalidate Cache & Restart

之后不再有致命信号。我确定它与分析器有关,但不能确定。我只知道重新启动 AS 停止了我的模拟器上的崩溃。 在此处输入图像描述

于 2020-10-27T17:48:00.620 回答
13

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

android:hardwareAccelerated="false"
于 2018-01-29T09:05:28.540 回答
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

一个非常糟糕的做法:/

于 2017-04-06T10:39:28.673 回答
5

使用这样的位图时出现此错误:

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

对我来说解决问题的是减小位图的大小(> 1000px 高到 700px)。

于 2015-11-12T18:16:27.377 回答
4

我在Android 4.4.4(Nexuses,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 成功处理

于 2016-03-24T11:36:45.247 回答
3

我刚从迁移android.supportandroidx.

问题是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;

在那之后,所有的问题都消失了。

于 2019-04-04T10:53:46.380 回答
2

如果您正在使用 vitamio 库并且发生此致命错误。

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

于 2018-06-12T09:32:47.017 回答
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 开发人员,如果您有同样的问题,请检查您的绑定...

于 2019-06-16T07:17:04.250 回答
2

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

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

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

由于我们的本机 C 代码不在 Java 目录中,因此不知道导致问题的确切代码行。所以我建议你检查你的 .cpp 文件并尝试在那里找到任何线索。

于 2019-12-26T12:43:47.157 回答
2

尝试“应用更改并重新启动 Activity”时,我在 Android Studio 中遇到了这个问题,因为那时应用程序无法启动。原因是我尝试了这个可能在片段内,但我不得不重新启动用于测试我的应用程序的手机,然后问题就消失了。

于 2021-10-13T13:02:00.170 回答
1

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

具有讽刺意味的是,它还导致了应用程序中的极端性能问题。

于 2018-07-02T17:20:34.300 回答
1

我为此苦苦挣扎了好几个小时,最后才进入我正在调试的应用程序的存储详细信息并进行了“清除数据”。之后运行良好。就我而言,这是一些奇怪的谷歌服务 gms 错误。

于 2021-03-23T04:58:54.783 回答
1

我使用Flutter 2.8.1遇到了这个问题。

我搜索了很多,但没有任何帮助(禁用我正在使用的外部包、调试、使缓存无效、flutter clean、重新启动模拟器等)。

事实证明,这与CustomPainter我在课堂上所做的工作有关。即使是绘制一个简单的矩形也可能会导致这种崩溃。

我切换到 beta 频道(Flutter 2.9.0-0.1.pre),问题完全消失了。

于 2022-01-07T13:06:27.713 回答
0

检查您的 JNI/本机代码。我的一个参考是空的,但它是断断续续的,所以不是很明显。

于 2017-04-14T22:49:15.160 回答
0

检查你的原生函数,是否返回正确,如果没有返回请添加return语句。

于 2018-06-27T11:52:37.867 回答
0

对我来说,这个问题是由于两个活动之间的糟糕演员阵容造成的。我最近将此方法从 Activity1 移到了另一个 2。这样做,重构使这个显式转换保持原样。所以而不是做

((Activity1) mainActivity).hideDialog();

我应该做的

((Activity2) mainActivity).hideDialog();

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

*** 希望能帮助到你。

于 2018-11-18T12:34:33.790 回答
0

由于内存问题,我遇到了这个分段错误错误。我的结构有很多变量和数组,这个数组大小为 1024。

将大小减小到 512,错误就消失了。

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

于 2019-01-28T11:51:57.367 回答
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        
        }
    });
 }
于 2019-05-02T14:49:31.407 回答
0

我在添加到我的应用程序(FancyShowCaseView)的包中遇到了这个问题,并在 pre-lolipop 上导致了这个问题。该软件包是用 kotlin 编写的,而我的主要代码是用 java 编写的。所以现在我正在检查 pre-lolipop 中的版本,不要让它的类被执行。暂时解决了问题。看看这个如果你有像我一样的问题

于 2019-08-10T09:38:35.040 回答
0

我在使用 Android 的 PDF API 创建 PDF 时遇到了问题,我在关闭 pdf 页面后不小心使用了 canvas.save() 和 canvas.restore()。

于 2019-12-12T05:37:16.297 回答
0

将这两行添加到您的 build.gradle 的 android 部分:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}
于 2020-03-10T09:13:12.010 回答
0

在我使用 android 的 PdfDocument API 的情况下,该行your_pdf_doc_object.finishPage(your_page)应该位于画布抽屉的末尾,否则可能会产生内存异常或内存泄漏。

于 2021-03-04T13:47:34.637 回答
0

当我使用ics-openvpn时发生此错误

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdead0000 in tid 3548

只需将“ x86 ”添加到“ abiFilters ”即可修复,如下所示

ndk {
   abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
}
于 2022-02-16T09:53:24.670 回答