Android致命信号11（SIGSEGV）在0x636f7d89（代码= 1）。 它如何被追查？
我一直在阅读其他文章，追踪在Android应用程序中获取SIGSEGV的原因。 我计划扫描我的应用程序可能的NullPointers相关的canvas使用，但我的SIGSEGV barfs上一个不同的内存地址每次。 另外我见过的code=1和code=2 。 如果内存地址是0x00000000 ，我会有一个线索，它是一个空指针。
我得到的最后一个是code=2 ：
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
有关如何跟踪这个问题的任何build议？
我有一个嫌疑犯，但我不想尝试它。 我的应用程序使用OSMDroid API进行离线映射。 OverlayItem类表示地图上的标记/节点。 我有一个服务，通过networking收集数据来填充OverlayItem，然后显示在地图上。 为了简化我的devise，我将OverlayItem扩展到了我自己的NodeOverlayItem类中，该类包含了我在UI活动和服务中使用的一些附加属性。 这给了我一个关于UI和服务的单项信息。 我使用Intents广播到活动刷新UI地图时，一些改变。 活动绑定到服务，并有一个服务方法来获取NodeOverlayItem的列表。 我想这可能是OSMDroid API使用OverlayItem，同时我的Service更新节点信息。 （并发问题）
当我写这篇文章时，我认为这确实是个问题。 令人头疼的是NodeOverlayItem没有将Node和OverlayItem分开，这就是Activity需要来自Node的一些数据，这个Service就是这样。 另外当Activity被创build时（onResume等等），OverlayItem对象将需要从活动不在时服务一直维护的Node数据重新创build。 例如，您启动应用程序，服务收集数据，用户界面显示它，你回家，然后回到应用程序，活动将需要拉动，并从最新的服务节点数据重新创buildOverlayItem的。
我知道这不是一个很好的或明确的问题。 这就像我所有的问题都是利基或模糊的。 如果任何人有关于如何解释这些SIGSEGV错误的build议，将不胜感激！
更新这是debugging会话期间捕获的最新的崩溃。 我有3个这些设备用于testing，当我正在开发和testing时，它们并不全部可靠地崩溃。 我包括了一些额外的东西，所以GC日志logging可以注意到。 你可以看到这个问题可能与内存耗尽无关。
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..FF... F 03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800 )F....pp.FhF 03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10 .Fh@+...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.#hB .#. 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工具链中find它）来查找崩溃的函数。 在这个例子中，你这样做
addr2line -e -f libc.so 0001173c
你会看到你的问题。 当然，这不会帮助你，因为它是在libc中。
所以你可以结合arm-eabi-objdump来find最终的目标。
相信我，这是一项艰巨的任务。
只是为了更新。 我认为我从整个源代码树开始进行Android本地构build已有相当长的一段时间，直到今天我已经仔细阅读了NDK文档。 自从发布NDK-r6以来，它提供了一个名为ndk-stack的实用程序。
以下是官方NDK文件与NDK-r9焦油球的内容。
概述：
ndk-stack是一个简单的工具，它允许你在堆栈轨迹出现在“adb logcat”的输出中时，过滤掉堆栈轨迹，并用相应的值replace共享库中的任何地址。
简而言之，它会翻译如下内容：
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构build系统（即ndk-build ），那么它们总是位于$ PROJECT_PATH / obj / local /下，其中代表设备的ABI（默认情况下是armeabi ）。
您可以将logcat文本作为直接input提供给程序，例如：
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
或者，您可以使用-dump选项将logcat指定为input文件，例如：
adb logcat > /tmp/foo.txt $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt
重要提示：
该工具在logcat输出中查找包含开始的初始行，即如下所示的内容：
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
当复制/粘贴轨迹时，不要忘记轨迹中的这一行，否则ndk-stack将无法正常工作。
去做：
未来版本的ndk-stack将尝试启动adb logcat并自动select库path。 目前，您必须手动执行这些步骤。
截至目前， ndk-stack不处理没有debugging信息的库。 尝试检测给定PC地址的最近的函数入口点（例如上面的libc.so示例）可能会很有用。
好！ 对于那些真正提交了评论和答案的人，我真的很抱歉，但是我发现了这个问题。 我不认为这会帮助很多其他人追查他们的个人SIGSEGV，但我的（这很难）完全与此有关：
https://code.google.com/p/android/issues/detail?id=8709
libcrypto.so在我的转储types的线索中。当我试图确定是否已经看到数据包，并跳过它，如果有的话，我做了一个MD5散列数据包的数据。 我曾经想过这是一个跟踪这些哈希的丑陋的线程问题，但事实certificate这是java.security.MessageDigest类！ 这不是线程安全的！
我用一个UID换出来，当时我根据设备UUID和一个时间戳填充每个数据包。 没有问题，因为。
我想我可以传授给那些在我的情况下的教训是，即使你是100％的Java应用程序，也要注意崩溃转储中提到的本地库和符号以寻找线索。 searchSIGSEGV + lib .so的名字将比无用的代码= 1等得多得多…接下来想想你的Java应用程序可以触及本地代码的位置，即使它不是你所做的。 我犯了一个错误，认为这是一个服务+ UI线程问题，Canvas画的是null（最常见的情况是我search了SIGSEGV），忽略了它可能与我写的代码完全相关与崩溃转储中的lib .so相关。 当然，java.security会使用libcrypto.so中的本地组件来提高速度，所以一旦我find了，我search了Android + SIGSEGV + libcrypto.so，并find了logging的问题。 祝你好运！
我也多次得到这个错误，我解决了它。 在本机端进行内存pipe理时将会遇到这个错误。
您的应用程序正在访问其地址空间之外的内存。 这很可能是一个无效的指针访问。 SIGSEGV =本地代码中的段错误。 由于它不在Java代码中发生，因此不会看到具有详细信息的堆栈跟踪。 但是，如果在应用程序进程崩溃后再查看一下，您可能仍会在logcat中看到一些堆栈跟踪信息。 它不会告诉你文件中的行号，但会告诉你在调用链中使用了哪些目标文件和地址。 从那里你可以经常找出代码的哪个部分是有问题的。 你也可以设置一个到目标进程的gdb本地连接，并在debugging器中捕获它。
我得到这个错误，保存一个对象作为一个gson转换string的共享首选项。 gsonstring不好，所以检索和反序列化的对象实际上并没有正常工作。 这意味着任何对对象的后续访问都会导致此错误。 害怕 ：）
使用这样的位图时，我得到这个错误：
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
什么解决了我的问题是减less位图的大小（> 1000px高到700px）。
我在Android 4.4.4（Nexus，Samsungs）面对SIGSEGV事实certificate，致命的错误是parsingnull 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成功处理
我尝试访问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
一个非常糟糕的做法：
检查你的JNI /本地代码。 我的一个参考资料是空的，但它是间歇性的，所以不是很明显。
