如何在Android中找出SIGSEGV的原因

Question

我的Android應用程序崩潰的報告越來越多，崩潰發生在本機代碼中，因此不會產生堆棧跟蹤。 我只有一個本機功能，這不是問題，因為它在啟動過程中被調用一次，問題發生在2-3分鍾后。

我從logcat獲得了以下部分轉儲：

I/DEBUG   ( 8704): pid: 9028, tid: 9136  >>> xxxx <<<
I/DEBUG   ( 8704): at : (2012-10-30 21:10:42.000086303 UTC) 0
I/DEBUG   ( 8704): signal 11 (SIGSEGV), fault addr deadbaad
I/DEBUG   ( 8704):  r0 00000000  r1 afd14691  r2 00000027  r3 00000070
I/DEBUG   ( 8704):  r4 afd42328  r5 00000000  r6 00000000  r7 0000a000
I/DEBUG   ( 8704):  r8 00000000  r9 4a77b900  10 4a77b8d8  fp 00000046
I/DEBUG   ( 8704):  ip 00001750  sp 4a77b590  lr deadbaad  pc afd11ce4  cpsr 60000030
I/DEBUG   ( 8704):  d0  643a64696f72646e  d1  6472656767756265
I/DEBUG   ( 8704):  d2  0000005d0000005b  d3  0006000600060006
I/DEBUG   ( 8704):  d4  0120009c009c009c  d5  000a000a000a000a
I/DEBUG   ( 8704):  d6  0012000600060006  d7  0000000000000000
I/DEBUG   ( 8704):  d8  0000004600000000  d9  43f0000000000000
I/DEBUG   ( 8704):  d10 4040000043080000  d11 0000000043ee464c
I/DEBUG   ( 8704):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 8704):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 8704):  d16 0505050507070707  d17 0b0b0b0b10101010
I/DEBUG   ( 8704):  d18 0707070703030303  d19 0000000000000000
I/DEBUG   ( 8704):  d20 0100010001000100  d21 0100010001000100
I/DEBUG   ( 8704):  d22 0000000000000000  d23 0000000000000000
I/DEBUG   ( 8704):  d24 0000000000000000  d25 0000000000000000
I/DEBUG   ( 8704):  d26 00f900f900f900f9  d27 00fb00fb00fb00fb
I/DEBUG   ( 8704):  d28 00f000f000f000f0  d29 00f500f500f500f5
I/DEBUG   ( 8704):  d30 01748000016e0000  d31 01818000017b0000
I/DEBUG   ( 8704):  scr 20000012
I/DEBUG   ( 8704): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 8704): Build fingerprint: \'lge/lge_bprj/lgp970/lgp970:2.2.2/FRG83G/V10a_07-JUN-2011.422D181D:user/release-keys\'
I/DEBUG   ( 8704):          #00  pc 00011ce4  /system/lib/libc.so
I/DEBUG   ( 8704):          #01  pc 0000be32  /system/lib/libc.so
I/DEBUG   ( 8704):          #02  pc 0000cd92  /system/lib/libc.so
I/DEBUG   ( 8704):          #03  pc 000008d8  /system/lib/libstdc++.so
I/DEBUG   ( 8704):          #04  pc 0004efa4  /system/lib/libskia.so
I/DEBUG   ( 8704):          #05  pc 0006d00c  /system/lib/libskia.so
I/DEBUG   ( 8704):          #06  pc 0006f414  /system/lib/libskia.so
I/DEBUG   ( 8704): 
I/DEBUG   ( 8704): code around pc:
I/DEBUG   ( 8704): afd11cc4 2d00682d e029d1fb b12b68db c05cf8df 
I/DEBUG   ( 8704): afd11cd4 f8442001 4798000c e054f8df 26002227 
I/DEBUG   ( 8704): afd11ce4 2000f88e eecaf7fb f7fc2106 f04feff8 
I/DEBUG   ( 8704): afd11cf4 91035180 460aa901 96012006 f7fc9602 
I/DEBUG   ( 8704): afd11d04 a905eb6e 20024632 eb78f7fc eeb6f7fb 
I/DEBUG   ( 8704): 
I/DEBUG   ( 8704): code around lr:
I/DEBUG   ( 8704): deadba8c ffffffff ffffffff ffffffff ffffffff 
I/DEBUG   ( 8704): deadba9c ffffffff ffffffff ffffffff ffffffff 
I/DEBUG   ( 8704): deadbaac ffffffff ffffffff ffffffff ffffffff 
I/DEBUG   ( 8704): deadbabc ffffffff ffffffff ffffffff ffffffff 
I/DEBUG   ( 8704): deadbacc ffffffff ffffffff ffffffff ffffffff 
I/DEBUG   ( 8704): 
I/DEBUG   ( 8704): stack:
I/DEBUG   ( 8704):     4a77b550  00000015  
I/DEBUG   ( 8704):     4a77b554  afd146c1  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b558  afd425a0  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b55c  afd4254c  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b560  00000000  
I/DEBUG   ( 8704):     4a77b564  afd156db  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b568  afd14691  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b56c  afd14691  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b570  00000070  
I/DEBUG   ( 8704):     4a77b574  afd42328  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b578  00000000  
I/DEBUG   ( 8704):     4a77b57c  4a77b5a4  
I/DEBUG   ( 8704):     4a77b580  0000a000  [heap]
I/DEBUG   ( 8704):     4a77b584  afd14933  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b588  df002777  
I/DEBUG   ( 8704):     4a77b58c  e3a070ad  
I/DEBUG   ( 8704): #00 4a77b590  afd43904  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b594  afd103ec  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b598  afd42328  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b59c  49687628  
I/DEBUG   ( 8704):     4a77b5a0  49687628  
I/DEBUG   ( 8704):     4a77b5a4  fffffbdf  
I/DEBUG   ( 8704):     4a77b5a8  afd42328  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b5ac  afd4374c  /system/lib/libc.so
I/DEBUG   ( 8704):     4a77b5b0  49687628  
I/DEBUG   ( 8704):     4a77b5b4  afd0be37  /system/lib/libc.so
I/DEBUG   ( 8704): #01 4a77b5b8  49687660  
I/DEBUG   ( 8704):     4a77b5bc  00430a60  [heap]
I/DEBUG   ( 8704):     4a77b5c0  00001424  
I/DEBUG   ( 8704):     4a77b5c4  4a77b8b0  
I/DEBUG   ( 8704):     4a77b5c8  00000000  
I/DEBUG   ( 8704):     4a77b5cc  49687628  
I/DEBUG   ( 8704):     4a77b5d0  49687628  
I/DEBUG   ( 8704):     4a77b5d4  00000000  
I/DEBUG   ( 8704):     4a77b5d8  4a77b8b0  
I/DEBUG   ( 8704):     4a77b5dc  afd0cd95  /system/lib/libc.so

我的問題：

我知道我可以找到sigsegv從中發生的本機函數，但是我不知道在哪里可以找到本機庫。它發生在用戶的手機上，我無法直接訪問它或者對用戶...是否有一個包含這些庫的網站，或者我可以在它們與手機上的那些庫存時保持一致嗎？ 或者有更好的方法來調試這些？

感謝閱讀，歡迎任何想法:-)

更新：

正如所建議的那樣，使用ndk-stack如下：

./ndk-stack -sym LONGPATH/armeabi -dump foo.txt

其中foo.txt包含“構建指紋”的東西，從一個有很多星星的行開始（它搜索那個），但我得到的是：

********** Crash dump: **********
Build fingerprint: \'lge/lge_bprj/lgp970/lgp970:2.2.2/FRG83G/V10a_07-JUN-2011.422D181D:user/release-keys\'

程序停止..

EDIT2：

使用arm-linux-androideabi-addr2line和下載的FRG83G ROM我得到了更多：

它指向dlmalloc_trim alarm， dlmalloc_trim和realloc ，在ligstdc ++中刪除。以及SI8_D16_filter_DXDY中的drawBitmap ， clipQuad ，clipQuad

現在來了有趣的部分，如何處理這些信息..明天我會繼續，這是0530這里..

EDIT3：

我更進了一步但再次卡住，轉儲中的pc值指向libskia.so中的函數，我發現在多個線程中同時使用Paint對象會導致這個問題，我不這樣做但是我確實重用了BitmapFactory.Options ，希望那是問題，我刪除了那部分，仍然崩潰......轉儲指向SkBitmapProcShader::SkBitmapProcShader ， SkTriColorShader::shadeSpan和SkDraw::drawBitmap 。 最后一個是指向位圖問題最明顯的..但它不是BitmapFactory.Options或Paint對象..

Answer 1

為了找到信號11的原因，你必須使用ndk-stack工具。 如有任何幫助，請使用以下鏈接作為參考

http://yssays.wordpress.com/2011/12/27/android-ndk-stack-tool/

Answer 2

“我只有一​​個本機功能，這不是問題，因為它在啟動過程中被調用一次，問題發生在2-3分鍾后。”

Bzzzztt！ 錯誤。 完全有可能在一個地方丟棄內存....然后當你嘗試訪問程序中完全不同的部分（現在已損壞的）內存時失敗。

我假設你正在使用NDK。

建議：

1）在任何全局內存或malloc'ed緩沖區周圍放置“sentinel”值。

2）仔細檢查所有“malloc（）”（“deadbaad”聽起來像是從堆中分配的東西）

3）在這里查看有關使用ndk-gdb的提示：

• http://mhandroid.wordpress.com/2011/01/25/how-cc-debugging-works-on-android/

PS：

你的本機代碼是C還是C ++？