如何在致命信號11之後在logcat中使用輸出以找出我從android本機代碼中獲取錯誤的位置？

我有一個bug修復彈出很多。它的致命信號11.問題是程序不會在我的任何本地代碼中崩潰，但其他的事情正在導致它。我已在從logcat的下面，我不知道這樣做的正確的術語：如何在致命信號11之後在logcat中使用輸出以找出我從android本機代碼中獲取錯誤的位置？

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... [email protected] 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba84 e1a04000 3a000004 eddf7a09 edc07a01 [email protected]:.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

通常當我得到這樣那樣的錯誤，這是因爲一些本地代碼我寫搞亂了，就像訪問一個矢量的無效元素或其他東西。

這個問題通常發生在我的一個本地函數運行後（但不在其中），所以當我沒有得到問題發生的行號時，我很難弄清楚如何修復它。有沒有一種方法可以使用此輸出來獲取有關此問題的更多信息？我不知道這個輸出的合適名詞是什麼，所以我很難找到答案。如果有人在這裏有經驗，我真的很想能夠使用它！

感謝，扎克

來源

2013-03-10 Zach

對於初學者，您可以在您的本機代碼中添加日誌以查明錯誤 – 2013-03-10 17:44:44

這就是我所做的，錯誤不會發生在我的本機代碼中。 – Zach 2013-03-10 17:47:15

可以粘貼部分日誌上面的點你得到這個錯誤，也檢查這篇文章http://stackoverflow.com/questions/10423128/android-fatal-signal-11 – 2013-03-10 17:52:16

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）

所以這顯然是一個系統/框架問題。我會嘗試創建一個最小代碼來重現問題，以瞭解其性質並搜索已知的錯誤報告。最好的辦法是找到一個解決方法，不要碰到這段代碼路徑。

來源

2013-03-11 10:38:30 auselen

這可能是問題是與類的方式是正在使用，崩潰可以在應用程序源中糾正。 'isEmpty（）'不是一個虛擬方法，所以'this'指針可能是空的。（這種方法實際上並沒有太多的工作，所以可能會出錯的一組內容是有限的。）如果你想斷言在這種情況下它仍然是圖書館的錯誤，我不會爭辯。 :-) – fadden 2013-03-13 00:34:32

@fadden我不知道函數有多深，但是「r0 004a1e30 r1 33400001 r2 004a1e30 r3 00000000」它是r3，它是空的。 '這個'應該在'r0' afaik上，但是我的C++調試技能不在專家那裏。 – auselen 2013-03-13 07:35:12

嗯。看着反彙編，我猜'this'是有效的，但'fPathRef'是'NULL'。（第一條指令將*（R0 + 0）加載到R3中，第二條指令將*（R3 + 16）加載到R0中，接下來的兩條比較R0爲零，並將它保存爲R0中的一個bool，並在第二條指令上崩潰。什麼情況導致這種狀態。 – fadden 2013-03-13 17:14:56

如何在致命信號11之後在logcat中使用輸出以找出我從android本機代碼中獲取錯誤的位置？

回答

相關問題