Android开发中利用ndk-stack解决ndk开发中动态库.so崩溃的问题

http://www.drovik.com/ 2012-12-12 13:11:37 来源：Steersman原创点击：

转自请注明出处：http://www.drovik.com/html/4718091137.html 谢谢

先上一段令人崩溃的堆栈体验一番！

12-10 09:18:57.360: I/DEBUG(21151): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

12-10 09:18:57.360: I/DEBUG(21151): Build fingerprint: 'telechips/full_m801/m801:2.3.3/GRI40/20110906.062149:eng/test-keys'

12-10 09:18:57.360: I/DEBUG(21151): pid: 21175, tid: 21178 >>> com.gui <<<

12-10 09:18:57.360: I/DEBUG(21151): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000

12-10 09:18:57.360: I/DEBUG(21151): r0 ffffffff r1 31322000 r2 00000004 r3 00351a88

12-10 09:18:57.360: I/DEBUG(21151): r4 00000000 r5 31322000 r6 afd46478 r7 00000000

12-10 09:18:57.360: I/DEBUG(21151): r8 100ffe54 r9 afd46478 10 00000000 fp acaa4d38

12-10 09:18:57.360: I/DEBUG(21151): ip afd24d8d sp 100ffe20 lr afd24d85 pc aca6a72a cpsr 00000030

12-10 09:18:57.360: I/DEBUG(21151): d0 00000000001c2000 d1 0000004800000002

12-10 09:18:57.360: I/DEBUG(21151): d2 4e4701da42917400 d3 42c8000000af1f00

12-10 09:18:57.360: I/DEBUG(21151): d4 00000000007f5d58 d5 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d6 0000000000000000 d7 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d8 0000000000000000 d9 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d10 ffffffffffffffff d11 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d12 0000000000000000 d13 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d14 0000000000000000 d15 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d16 00000000014f2b54 d17 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d18 0000000000000000 d19 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d20 0000000000000000 d21 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d22 0000000000000000 d23 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d24 0000000000000000 d25 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d26 0000000000000000 d27 0000000000000000

12-10 09:18:57.360: I/DEBUG(21151): d28 00ff00ff00ff00ff d29 00ff00ff00ff00ff

12-10 09:18:57.360: I/DEBUG(21151): d30 01d0800001cbc000 d31 01da000001d54000

12-10 09:18:57.360: I/DEBUG(21151): scr 80000012

12-10 09:18:57.530: I/DEBUG(21151): #00 pc 0006a72a /system/lib/libdvm.so

12-10 09:18:57.530: I/DEBUG(21151): #01 lr afd24d85 /system/lib/libc.so

12-10 09:18:57.530: I/DEBUG(21151): code around pc:

12-10 09:18:57.530: I/DEBUG(21151): aca6a708 021ff113 657ef421 607ef422 051ff025

12-10 09:18:57.530: I/DEBUG(21151): aca6a718 001ff020 d20742a8 22041a2d f7a64629

12-10 09:18:57.530: I/DEBUG(21151): aca6a728 6821efb2 6025194d bf00bd70 48114601

01-27 10:39:01.760: I/DEBUG(788): Build fingerprint: 'telechips/full_m801/m801:2.3.3/GRI40/20111027.154026:eng/test-keys'

01-27 10:39:01.760: I/DEBUG(788): pid: 1373, tid: 1624 >>> com.iped.ipcam.gui <<<

01-27 10:39:01.760: I/DEBUG(788): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr fff0ffe8

01-27 10:39:01.760: I/DEBUG(788): r0 00000000 r1 fff0ffc8 r2 40009328 r3 400091e8

01-27 10:39:01.760: I/DEBUG(788): r4 00005cb8 r5 40009228 r6 405d4828 r7 aca9f600

01-27 10:39:01.760: I/DEBUG(788): r8 fffffe84 r9 80000000 10 400091e8 fp 405d4900

01-27 10:39:01.760: I/DEBUG(788): ip acaa4d38 sp 45418f70 lr aca308d0 pc aca2fc1c cpsr a8000010

01-27 10:39:01.760: I/DEBUG(788): d0 0000000000096000 d1 002e002e002e0000

01-27 10:39:01.760: I/DEBUG(788): d2 002e002e002e0000 d3 002e002e002e0000

01-27 10:39:01.760: I/DEBUG(788): d4 002e002e002e002e d5 002e002e001e0016

01-27 10:39:01.760: I/DEBUG(788): d6 002e002e002e002e d7 002e002e002e002e

01-27 10:39:01.760: I/DEBUG(788): d8 0000007eacc8f4e0 d9 4680000000000004

01-27 10:39:01.760: I/DEBUG(788): d10 4356000042600000 d11 0000000043560000

01-27 10:39:01.760: I/DEBUG(788): d12 0000000000000000 d13 0000000000000000

01-27 10:39:01.760: I/DEBUG(788): d14 0000000000000000 d15 0000000000000000

01-27 10:39:01.760: I/DEBUG(788): d16 1010101010101010 d17 0000800000008000

01-27 10:39:01.760: I/DEBUG(788): d18 ffd4cb1affd52334 d19 ffa54dd2ffa604a4

01-27 10:39:01.760: I/DEBUG(788): d20 ffffa7e6ffffa7e6 d21 ffff492effff492e

01-27 10:39:01.760: I/DEBUG(788): d22 0001c5a20001c5a2 d23 000166e9000166e9

01-27 10:39:01.760: I/DEBUG(788): d24 0000000200000002 d25 020406111a1b2925

01-27 10:39:01.760: I/DEBUG(788): d26 020406111a1b2925 d27 e6e6e7e8eaeaedec

01-27 10:39:01.760: I/DEBUG(788): d28 00ff00ff00ff00ff d29 3ff0000000000000

01-27 10:39:01.760: I/DEBUG(788): d30 0000000000000000 d31 3ff0000000000000

01-27 10:39:01.760: I/DEBUG(788): scr 80000013

01-27 10:39:01.920: I/DEBUG(788): #00 pc 0002fc1c /system/lib/libdvm.so

01-27 10:39:01.920: I/DEBUG(788): #01 pc 000308cc /system/lib/libdvm.so (dvmHeapScanMarkedObjects)

01-27 10:39:01.920: I/DEBUG(788): #02 pc 0001a350 /system/lib/libdvm.so (dvmCollectGarbageInternal)

01-27 10:39:01.920: I/DEBUG(788): code around pc:

01-27 10:39:01.920: I/DEBUG(788): aca2fbfc 0a000001 e1a01006 eb0145a7 e797c008

01-27 10:39:01.930: I/DEBUG(788): aca2fc0c e5961000 e59c20ac e1510002 0a0000b5

01-27 10:39:01.930: I/DEBUG(788): aca2fc1c e5912020 e3120101 0a000055 e3510000

01-27 10:39:01.930: I/DEBUG(788): aca2fc2c e1a03001 0a000021 e5950010 e1510000

01-27 10:39:01.930: I/DEBUG(788): aca2fc3c 3a00001e e5953000 e593c00c e5930010

01-27 10:39:01.930: I/DEBUG(788): code around lr:

01-27 10:39:01.930: I/DEBUG(788): aca308b0 e58de004 e16f2f17 e59d3004 e585b014

01-27 10:39:01.930: I/DEBUG(788): aca308c0 e1a01005 e1c77239 e0830182 ebfffcc0

01-27 10:39:01.930: I/DEBUG(788): aca308d0 e3570000 1afffff6 e598c010 e598100c

01-27 10:39:01.930: I/DEBUG(788): aca308e0 e061000c e1a02420 eaffffdb 0006eddc

01-27 10:39:01.930: I/DEBUG(788): aca308f0 fffffe84 e1a03001 e59f104c e92d4030

01-27 10:39:01.930: I/DEBUG(788): stack:

01-27 10:39:01.930: I/DEBUG(788): 45418f30 504b9827

01-27 10:39:01.930: I/DEBUG(788): 45418f34 c8928508

01-27 10:39:01.930: I/DEBUG(788): 45418f38 704d5839

01-27 10:39:01.930: I/DEBUG(788): 45418f3c 80c48688 /system/lib/libMali.so

01-27 10:39:01.930: I/DEBUG(788): 45418f40 690413fe

01-27 10:39:01.930: I/DEBUG(788): 45418f44 fffffe84

01-27 10:39:01.930: I/DEBUG(788): 45418f48 4456cfe4

01-27 10:39:01.930: I/DEBUG(788): 45418f4c 00005314

01-27 10:39:01.930: I/DEBUG(788): 45418f50 40009228

01-27 10:39:01.930: I/DEBUG(788): 45418f54 4053a4a0

01-27 10:39:01.930: I/DEBUG(788): 45418f58 aca9f600

01-27 10:39:01.930: I/DEBUG(788): 45418f5c fffffe84

01-27 10:39:01.930: I/DEBUG(788): 45418f60 80000000 /system/lib/libtslib.so

01-27 10:39:01.930: I/DEBUG(788): 45418f64 400091e8

01-27 10:39:01.930: I/DEBUG(788): 45418f68 df002777

01-27 10:39:01.930: I/DEBUG(788): 45418f6c e3a070ad

01-27 10:39:01.930: I/DEBUG(788): #00 45418f70 00005cb8

01-27 10:39:01.930: I/DEBUG(788): 45418f74 40009228

01-27 10:39:01.930: I/DEBUG(788): 45418f78 005cb900

01-27 10:39:01.930: I/DEBUG(788): 45418f7c 00000000

01-27 10:39:01.930: I/DEBUG(788): 45418f80 400092fc

01-27 10:39:01.930: I/DEBUG(788): 45418f84 80000000 /system/lib/libtslib.so

01-27 10:39:01.930: I/DEBUG(788): 45418f88 400091e8

01-27 10:39:01.930: I/DEBUG(788): 45418f8c aca308d0 /system/lib/libdvm.so

01-27 10:39:01.930: I/DEBUG(788): #01 45418f90 00000003

01-27 10:39:01.930: I/DEBUG(788): 45418f94 405d4800

01-27 10:39:01.930: I/DEBUG(788): 45418f98 fffffe84

01-27 10:39:01.930: I/DEBUG(788): 45418f9c 400091e8

01-27 10:39:01.930: I/DEBUG(788): 45418fa0 aca9f600

01-27 10:39:01.930: I/DEBUG(788): 45418fa4 00000003

01-27 10:39:01.930: I/DEBUG(788): 45418fa8 fffffe8c

01-27 10:39:01.930: I/DEBUG(788): 45418fac fffffe84

01-27 10:39:01.930: I/DEBUG(788): 45418fb0 00002710

01-27 10:39:01.930: I/DEBUG(788): 45418fb4 acaa4d38

01-27 10:39:01.930: I/DEBUG(788): 45418fb8 00000001

01-27 10:39:01.930: I/DEBUG(788): 45418fbc aca1a354 /system/lib/libdvm.so

利用Android NDK开发本地应用的时候，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。

前段时间，写了一篇文章，说的是根据log堆栈利用arm-eabi-addr2line工具快速定位错误代码所在的行数，文章地址：http://drovik.com/html/693701255.html。虽然比单靠打印来定位错误行数要简单不少，但也是一件相当繁琐的过程。

今天来记录一下如何根据log堆栈利用android ndk自带的工具ndk-stack快速定位错误信息。

首先需要说明的是ndk-stack是从NDK r6开始才有工具。

接下来详细说明ndk-stack的使用方法。

第一步：首先获得发生崩溃的共享库。

如果你是利用ndk-build应用的话，共享库会在$PROJECT_PATH/obj/local/armeabi/目录下。

第二部：定位错误代码：

a、通过adb直接将log信息导入到程序中

adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

b、先将log信息导入到文件，然后再把日志文件导入到程序当中

adb logcat > /tmp/foo.txt

$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump /tmp/foo.txt

重要说明：

保存log信息到文件的时候，一定要将含有“*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ”的这一行拷贝到文件中，否则ndk-stack不会正常工作。

相关文章: Android开发中如何改变RadioButton背景图片和文字的相对位置 (306人浏览); android中“You cannot combine custom title (405人浏览); Android ViewPager代码实例 (1208人浏览); Android中 BuildConfig.java的讨论 (53人浏览); android资源动态合并:Immutable bitmap passed to (31人浏览); android开发环境之ADT安装，卸载，更新 (15人浏览); 在Ubuntu中用Android NDK编译FFmpeg (447人浏览)

Tags：android ndk开发 ndk调试 ndk-stack用法 .so崩溃 arm-eabi-addr2line工具

分享到：

发表评论(2)

1楼 ndk-stack 发表于 2013-3-2 12:47:21: 请问使用ndk-stack时提示：Unable to open symbol file (9): Bad file descriptor 是怎么回事？谢谢！

2楼正解发表于 2013-6-3 16:27:18: /jni$ ndk-stack -sym ../libs/armeabi -dump ../libs/armeabi/foo.txt

查看更多评论>>>

Android软件开发

个人档案

我的网购

精彩相册

博客分类

热门文章

友情链接

姓名	*
评论内容	*
验证码	*