我一直在阅读有关追踪在Android应用中获取SIGSEGV
的原因的其他帖子。我打算在我的应用程序中搜索与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映射。 Activity绑定到Service,并且有一个Service方法来获取NodeOverlayItem的列表。我认为可能是OSMDroid API使用OverlayItem,而我的服务同时更新节点信息。 (并发问题)
在我写这篇文章时,我认为这确实是问题所在。令人头疼的是没有从NodeOverlayItem拆分Node和OverlayItem,而是Activity需要来自Node的一些数据,服务保存。另外,当创建Activity(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
首先,获取墓碑堆栈跟踪,每次应用程序崩溃时都会打印出来。像这样的东西:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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文件与NDK-r9焦油球的内容。
概述:
ndk-stack
是一个简单的工具,允许您过滤堆栈跟踪,因为它们出现在'adb logcat'的输出中,并用相应的:value替换共享库中的任何地址。
简而言之,它将翻译如下:
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
输出中查找包含start的初始行,即看起来像:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
复制/粘贴跟踪时,不要忘记跟踪中的这一行,否则ndk-stack
将无法正常工作。
ALL:
未来版本的ndk-stack
将尝试启动adb logcat
并自动选择库路径。目前,您必须手动执行这些步骤。
截至目前,ndk-stack
不处理其中没有调试信息的库。尝试检测到给定PC地址的最近函数入口点可能是有用的(例如,如上面的libc.so示例中那样)。
如果您正在使用vitamio库,则会发生此致命错误。
然后确保在项目中gradle targetSdkVersion必须小于23。
谢谢。
在我的情况下,问题是由Android Profiler引起的。在Android Studio中,单击“Android Profiler”和“结束会话”。
具有讽刺意味的是,它也在应用程序中引起了极端性能问题。
检查您的JNI /本机代码。我的一个引用是null,但它是间歇性的,所以它不是很明显。
检查你的原生函数,无论它是否正确返回,如果没有返回,请添加return语句。
对我来说,这个问题是由于两个活动之间的错误演员造成的。我最近将此方法从Activity1移动到另一个2.这样做,重构就像以前一样离开了这个显式的转换。所以不要这样做
((Activity1) mainActivity).hideDialog();
我应该这样做
((Activity2) mainActivity).hideDialog();
注意:但是这个错误没有发生在Android 8.0上我还不确定为什么。
*** 希望能帮助到你。
由于内存问题,我有这个分段错误错误。我的结构有很多变量和数组,这个数组大小为1024。
将大小减小到512,错误消失了。
P.S:这是一种解决方法而不是解决方案。有必要找到结构大小和动态内存分配是一个更好的选择。
在从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;
之后,所有问题都消失了。
当我在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
}
});
}
在我的情况下(我正在使用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开发人员,如果您遇到同样的问题,请检查您的绑定...
好!我真的很抱歉那些实际提交了意见和答案的人,但我发现了问题。我不认为这会帮助很多其他人试图追踪他们的个人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应用程序可以触及本机代码的位置,即使你没有做任何事情。我犯了一个错误,假设它是一个Service + UI线程问题,其中Canvas正在绘制一些空的东西,(我在SIGSEGV上搜索的最常见的情况)并忽略了它可能与我写的代码完全相关的可能性。与崩溃转储中的lib .so相关。当然java.security会在libcrypto.so中使用本机组件来提高速度,所以一旦我知道,我用Google搜索了Android + SIGSEGV + libcrypto.so并找到了记录的问题。祝好运!
我通过将对象保存为共享首选项作为gson转换字符串来获取此错误。 gson String并不好,因此检索和反序列化对象实际上并没有正常工作。这意味着对对象的任何后续访问都会导致此错误。害怕 :)
我也多次得到这个错误,我解决了。在本机端的内存管理情况下将面临此错误。
您的应用程序正在访问其地址空间之外的内存。这很可能是无效的指针访问。 SIGSEGV =本机代码中的分段错误。由于它不是在Java代码中出现的,因此您不会看到包含详细信息的堆栈跟踪。但是,如果在应用程序进程崩溃后环顾四周,您仍然可以在logcat中看到一些堆栈跟踪信息。它不会告诉您文件中的行号,但会告诉您调用链中正在使用哪些目标文件和地址。从那里你经常可以找出代码的哪个区域有问题。您还可以设置与目标进程的gdb本机连接,并在调试器中捕获它。
今天我遇到了Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
问题,我为了解决这个问题而奋斗了半天。
我尝试了许多清除缓存和删除.gradle文件的东西。
最后我disable Instant Run
,现在我再也没有得到这个问题。现在我的应用程序在启用即时运行后也正常工作。它可能是即时运行问题,请尝试禁用并启用即时运行
来自this回答:
转到Android Studio设置或首选项(对于MAC) - >构建,执行,部署 - >即时运行。
然后取消选中顶部的“启用即时运行”复选框。
当我试图访问onDraw()
之外的'canvas'时,我遇到了这个错误
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
一个非常糟糕的做法:/
尝试在清单中禁用Android硬件加速。
android:hardwareAccelerated="false"
我在使用这样的位图时遇到此错误:
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
解决这个问题的方法是减小位图的大小(> 1000px高到700px)。
我在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成功处理了它