如何在致命信号 11 之后使用 logcat 中的输出来找出我在 android 本机代码中从哪里得到错误？
Posted
技术标签:
【中文标题】如何在致命信号 11 之后使用 logcat 中的输出来找出我在 android 本机代码中从哪里得到错误？【英文标题】：How can i use the output in logcat after a Fatal Signal 11 to figure out where I am getting the error from in android native code? 【发布时间】：2013-02-25 20:13:54 【问题描述】：我有一个要修复的错误经常弹出。它是一个致命的信号 11。问题是程序在我的任何本机代码中都没有崩溃，但其他原因导致了它。我从 logcat 得到以下信息，我不知道这个的正确术语：
03-10 12:50:14.419 F/libc (3429): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
03-10 12:50:14.819 I/DEBUG (11778): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-10 12:50:14.819 I/DEBUG (11778): Build fingerprint: 'hp/hp_tenderloin/tenderloin:4.0.4/IMM76I/330937:user/release-keys'
03-10 12:50:14.819 I/DEBUG (11778): pid: 3429, tid: 3702 >>> com.RefinedCode.handocr <<<
03-10 12:50:14.819 I/DEBUG (11778): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
03-10 12:50:14.819 I/DEBUG (11778): r0 004a1e30 r1 33400001 r2 004a1e30 r3 00000000
03-10 12:50:14.819 I/DEBUG (11778): r4 414b3da8 r5 004b6cb8 r6 00000007 r7 4e348f80
03-10 12:50:14.819 I/DEBUG (11778): r8 4e766c10 r9 4e348f78 10 00000008 fp 4e766c24
03-10 12:50:14.819 I/DEBUG (11778): ip 2ac56f9c sp 4e766c08 lr 2ac254dd pc 2b10ba64 cpsr 60010010
03-10 12:50:14.819 I/DEBUG (11778): d0 0000000000000000 d1 0000000000000000
03-10 12:50:14.819 I/DEBUG (11778): d2 0000000000000000 d3 0000000000000000
03-10 12:50:14.819 I/DEBUG (11778): d4 4379000044310000 d5 437a0000442d8000
03-10 12:50:14.819 I/DEBUG (11778): d6 bff921fb54400000 d7 442a556b00000000
03-10 12:50:14.819 I/DEBUG (11778): d8 4392103d3089705f d9 45a820003c711706
03-10 12:50:14.829 I/DEBUG (11778): d10 3f80000000000000 d11 3f800000000000ff
03-10 12:50:14.829 I/DEBUG (11778): d12 4017ef9a000000ff d13 000000003f800000
03-10 12:50:14.829 I/DEBUG (11778): d14 3fee940d6bb98cc4 d15 3ff0000000000000
03-10 12:50:14.829 I/DEBUG (11778): d16 0000000000000000 d17 0000000042ff0000
03-10 12:50:14.829 I/DEBUG (11778): d18 3fc5555555555549 d19 bf9b6d5dd2eaade7
03-10 12:50:14.829 I/DEBUG (11778): d20 3ef4e83ec07d9f84 d21 be5ae1fd202f348f
03-10 12:50:14.829 I/DEBUG (11778): d22 bc7a626331000000 d23 3de5d93a5acfd57c
03-10 12:50:14.829 I/DEBUG (11778): d24 ff00000000000000 d25 0000d8050000a9d8
03-10 12:50:14.829 I/DEBUG (11778): d26 0003e14a0018a8a0 d27 0002d8070002a9da
03-10 12:50:14.829 I/DEBUG (11778): d28 0000000000ff0000 d29 090a0b0c0d0e0f10
03-10 12:50:14.829 I/DEBUG (11778): d30 0000000100000001 d31 0000000100000001
03-10 12:50:14.829 I/DEBUG (11778): scr 60000010
03-10 12:50:14.829 I/DEBUG (11778):
03-10 12:50:14.999 I/DEBUG (11778): #00 pc 00088a64 /system/lib/libskia.so (_ZNK6SkPath7isEmptyEv)
03-10 12:50:14.999 I/DEBUG (11778): #01 pc 0006e4da /system/lib/libandroid_runtime.so
03-10 12:50:15.009 I/DEBUG (11778): #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke)
03-10 12:50:15.009 I/DEBUG (11778): #03 pc 00059050 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-10 12:50:15.009 I/DEBUG (11778):
03-10 12:50:15.009 I/DEBUG (11778): code around pc:
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba44 e5903014 e3530000 03a00001 012fff1e .0....S......./.
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba54 e3530001 13a00000 112fff1e e590300c ..S......./..0..
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba64 e5d30000 e2700001 33a00000 e12fff1e ......p....3../.
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba74 e1a03002 e5912008 e92d4010 e1530002 .0... ...@-...S.
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba84 e1a04000 3a000004 eddf7a09 edc07a01 .@.....:.z...z..
03-10 12:50:15.009 I/DEBUG (11778):
03-10 12:50:15.009 I/DEBUG (11778): code around lr:
03-10 12:50:15.009 I/DEBUG (11778): 2ac254bc ed78f7ca 463a4621 4605466e f7fc4668 ..x.!F:FnF.FhF..
03-10 12:50:15.009 I/DEBUG (11778): 2ac254cc 4628faa3 bdf0b005 4610b510 ed70f7ca ..(F.......F..p.
03-10 12:50:15.009 I/DEBUG (11778): 2ac254dc bf00bd10 4610b510 f7ca4619 bd10ed70 .......F.F..p...
03-10 12:50:15.009 I/DEBUG (11778): 2ac254ec 4610b510 ed70f7ca bf00bd10 4610b510 ...F..p........F
03-10 12:50:15.009 I/DEBUG (11778): 2ac254fc ed70f7ca bf00bd10 2030b570 f7c74615 ..p.....p.0 .F..
03-10 12:50:15.009 I/DEBUG (11778):
03-10 12:50:15.009 I/DEBUG (11778): stack:
03-10 12:50:15.009 I/DEBUG (11778): 4e766bc8 004b5270 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766bcc 004a1ac0 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766bd0 1d600005
03-10 12:50:15.009 I/DEBUG (11778): 4e766bd4 2b2e62e3 /system/lib/libdvm.so
03-10 12:50:15.009 I/DEBUG (11778): 4e766bd8 004b2de0 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766bdc 004b6cb8 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766be0 004b2de0 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766be4 2ac1c5c1 /system/lib/libandroid_runtime.so
03-10 12:50:15.009 I/DEBUG (11778): 4e766be8 41477d58 /dev/ashmem/dalvik-LinearAlloc (deleted)
03-10 12:50:15.009 I/DEBUG (11778): 4e766bec 004b6cb8 [heap]
03-10 12:50:15.009 I/DEBUG (11778): 4e766bf0 00000004
03-10 12:50:15.009 I/DEBUG (11778): 4e766bf4 4e348ee8
03-10 12:50:15.019 I/DEBUG (11778): 4e766bf8 2b524910 /dev/ashmem/dalvik-heap (deleted)
03-10 12:50:15.019 I/DEBUG (11778): 4e766bfc 2b524910 /dev/ashmem/dalvik-heap (deleted)
03-10 12:50:15.019 I/DEBUG (11778): 4e766c00 df0027ad
03-10 12:50:15.019 I/DEBUG (11778): 4e766c04 00000000
03-10 12:50:15.019 I/DEBUG (11778): #01 4e766c08 414b3da8 /dev/ashmem/dalvik-LinearAlloc (deleted)
03-10 12:50:15.019 I/DEBUG (11778): 4e766c0c 2b2b0db4 /system/lib/libdvm.so
通常当我遇到这种错误时，是因为我编写的一些本机代码搞砸了，比如访问向量的无效元素之类的。
问题通常发生在我的一个本机函数运行后（但不在其中），所以当我没有得到问题发生位置的行号时，我很难弄清楚如何解决它。有没有办法可以使用此输出来获取有关该问题的更多信息？我不知道这个输出的正确术语是什么，所以我很难寻找答案。如果这里有人有这方面的经验，我真的很想能够使用它！
谢谢， 扎克
【问题讨论】：
对于初学者，您可以在本机代码中添加日志以查明错误 这就是我所做的，错误不会发生在我的本机代码中。 你能不能把部分的日志粘贴到你得到这个错误的地方，也检查一下这个帖子***.com/questions/10423128/android-fatal-signal-11 【参考方案1】：Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) 是 null pointer dereferencing。如您所见地址为0x00000000，因此系统正在尝试从地址0 读取。
03-10 12:50:14.999 I/DEBUG (11778): #00 pc 00088a64 /system/lib/libskia.so (_ZNK6SkPath7isEmptyEv)
03-10 12:50:14.999 I/DEBUG (11778): #01 pc 0006e4da /system/lib/libandroid_runtime.so
03-10 12:50:15.009 I/DEBUG (11778): #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke)
03-10 12:50:15.009 I/DEBUG (11778): #03 pc 00059050 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
您的崩溃发生在SkPath7isEmptyEv - > SkPath.isEmpty()。 （这叫name mangling）
所以这显然是一个系统/框架问题。我会尝试创建一个最小的代码来重现该问题以了解其性质并搜索已知的错误报告。最好的办法是找到一个不触及此代码路径的解决方法。
【讨论】：
可能问题出在该类的使用方式上，并且可以在应用程序源中更正崩溃。isEmpty() 不是虚拟方法，因此 this 指针可能为空。 （这种方法确实没有多大作用，所以可能出错的事情是有限的。）如果你想断言在这种情况下库段错误仍然是一个错误，我不会争论。 :-)
@fadden 我不知道 PC 的功能有多深，但 "r0 004a1e30 r1 33400001 r2 004a1e30 r3 00000000" 它是 r3 为空。 this 应该在 r0 afaik 但是我的 c++ 调试技能远不及专家。
嗯。查看反汇编，我猜this 是有效的，但fPathRef 是NULL。 （第一条指令将 *(R0+0) 加载到 R3 中，第二条指令将 *(R3+16) 加载到 R0 中，接下来的两条指令将 R0 与零进行比较并将其保存为 R0 中的布尔值。第二条指令崩溃了。）不确定什么情况会导致这种状态。
感谢您的帮助！ Libskia似乎是android使用的图形库，我相信我的问题是由于没有同步对Path的访问引起的。这个名字修饰真的很有帮助。另外，很抱歉迟到了接受正确答案！以上是关于如何在致命信号 11 之后使用 logcat 中的输出来找出我在 android 本机代码中从哪里得到错误？的主要内容，如果未能解决你的问题，请参考以下文章
致命信号 11 (SIGSEGV) 在 0x00000000 (code=1) - PhoneGap
AsyncTask Android 中的致命信号 6 (SIGABRT)