android调试crash——反汇编

android调试crash——反汇编 2011-10-19
15:15:26

分类： LINUX

android调试crash——反汇编

转一位大牛的博文，对作者敬礼。以前也遇见过同样的问题，当时想的就是通过其他方法绕过去。看到大牛的解决方案，的确佩服万分。其实，以前在Moto的时候，遇见Core Dump问题几乎就是用同样方法来定位的。为啥自己以前就想不到呢？以后遇见问题一定要多动脑筋。

转自：http://my.unix-center.net/~Simon_fu/?p=527

在移植Android过程中会遇到很多Crash的事情。一般这些问题都可以通过看代码能解决，当然也有一些比较难搞的问题，非常难找到头绪，在 logcat日志也只会打印一些崩溃的堆栈，这些信息很难帮助我们定位问题。根据个人一个实例来介绍一下在Android移植过程中反汇编的用法。

首先先看一下我遇到的一个logcat关于Crash的打印信息：
I/DEBUG ( 1417): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

I/DEBUG ( 1417): Build fingerprint: 'generic/sdk/generic/:Eclair/ECLAIR/eng.simon.20100607.133011:eng/test-keys'

I/DEBUG ( 1417): pid: 1434, tid: 1460 >>> system_server <<<

I/DEBUG ( 1417): signal 11 (SIGSEGV), fault addr 00000000

I/DEBUG ( 1417): zr 00000000 at 00000000 v0 00007265 v1 00193228

I/DEBUG ( 1417): a0 00000001 a1 0000000a a2 00193228 a3 001f2ccf

I/DEBUG ( 1417): t0 00193228 t1 80000008 t2 8007e8dc t3 fffffff8

I/DEBUG ( 1417): t4 00030465 t5 00000000 t6 00200073 t7 00000000

I/DEBUG ( 1417): s0 2fa0786c s1 30564f00 s2 7ef5d990 s3 2fa0786c

I/DEBUG ( 1417): s4 30465000 s5 00100000 s6 7b10a8b4 s7 00000001

I/DEBUG ( 1417): t8 00000000 t9 7ef50d44 k0 00000000 k1 00000000

I/DEBUG ( 1417): gp 7ef6fd60 sp 30564e90 s8 2fa07858 ra 7ef53470

I/DEBUG ( 1417): hi 0000000f lo 04444444 bva 00007265 epc 7ef534a4

I/DEBUG ( 1417): #00 pc 7ef534a4 /system/lib/libc.so

I/DEBUG ( 1417): #01 ra 7ef53470 /system/lib/libc.so

I/DEBUG ( 1417):

I/DEBUG ( 1417): code around pc:

I/DEBUG ( 1417): 7ef53494 afa7002c afa40030 1040000b afa50028

I/DEBUG ( 1417): 7ef534a4 8c4a0000 8c440008 8c590004 8fa2001c

I/DEBUG ( 1417): 7ef534b4 0320f809 ac4a0034 8fa9001c 8d220034

I/DEBUG ( 1417):

I/DEBUG ( 1417): code around lr:

I/DEBUG ( 1417): 7ef53460 afbc0010 8f9987c4 0320f809 00808021

I/DEBUG ( 1417): 7ef53470 afa2001c 8fa8001c 8fa6001c 8fa3001c

I/DEBUG ( 1417): 7ef53480 8d07000c 8cc40010 8c650008 8c420034

I/DEBUG ( 1417):

I/DEBUG ( 1417): stack:

I/DEBUG ( 1417): 30564e50 00000000

I/DEBUG ( 1417): 30564e54 00000000

I/DEBUG ( 1417): 30564e58 00000000

I/DEBUG ( 1417): 30564e5c 00000000

I/DEBUG ( 1417): 30564e60 00009004

I/DEBUG ( 1417): 30564e64 00000000

I/DEBUG ( 1417): 30564e68 00000000

I/DEBUG ( 1417): 30564e6c 00000000

I/DEBUG ( 1417): 30564e70 00000009

I/DEBUG ( 1417): 30564e74 00000000

I/DEBUG ( 1417): 30564e78 00000000

I/DEBUG ( 1417): 30564e7c 7ef12af4 /system/lib/libc.so

I/DEBUG ( 1417): 30564e80 7ef6fd60

I/DEBUG ( 1417): 30564e84 00000000

I/DEBUG ( 1417): 30564e88 00000000

I/DEBUG ( 1417): 30564e8c 7ef53470 /system/lib/libc.so

I/DEBUG ( 1417): 30564e90 7ef6fd60

I/DEBUG ( 1417): 30564e94 00000000

I/DEBUG ( 1417): 30564e98 30564eb4

I/DEBUG ( 1417): 30564e9c 00000000

I/DEBUG ( 1417): 30564ea0 7ef6fd60

I/DEBUG ( 1417): 30564ea4 7b10a8e8 /system/lib/libsqlite.so

I/DEBUG ( 1417): 30564ea8 7b10a8b4 /system/lib/libsqlite.so

I/DEBUG ( 1417): 30564eac 00193228 [heap]

I/DEBUG ( 1417): 30564eb0 2fa07870

I/DEBUG ( 1417): 30564eb4 00000000

I/DEBUG ( 1417): 30564eb8 0000000a

I/DEBUG ( 1417): 30564ebc 001f2ccf [heap]

I/DEBUG ( 1417): 30564ec0 00000001

I/DEBUG ( 1417): 30564ec4 7ef537fc /system/lib/libc.so

I/DEBUG ( 1417): 30564ec8 00193228 [heap]

I/DEBUG ( 1417): 30564ecc 30564f00

I/DEBUG ( 1417): 30564ed0 7ef5d990 /system/lib/libc.so

I/DEBUG ( 1417): 30564ed4 2fa0786c

I/DEBUG ( 1417): 30564ed8 30465000

I/DEBUG ( 1417): 30564edc 00100000 [heap]

I/DEBUG ( 1417): 30564ee0 7b10a8b4 /system/lib/libsqlite.so

I/DEBUG ( 1417): 30564ee4 00000001

I/DEBUG ( 1417): 30564ee8 2fa07858

I/DEBUG ( 1417): 30564eec 7ef530ac /system/lib/libc.so

I/DEBUG ( 1417): 30564ef0 7b10a8b4 /system/lib/libsqlite.so

I/DEBUG ( 1417): 30564ef4 2fa0786c

I/DEBUG ( 1417): 30564ef8 00000000

I/DEBUG ( 1417): 30564efc 00000000

I/DEBUG ( 1417): 30564f00 30564f00

I/DEBUG ( 1417): 30564f04 00193228 [heap]

I/DEBUG ( 1417): 30564f08 00000009

I/DEBUG ( 1417): 30564f0c 00000000

I/DEBUG ( 1417): 30564f10 00000000

I/DEBUG ( 1417): 30564f14 00000000

W/SyncManager( 1434): Updating for new accounts...

通过这个log信息我们可以看到libc.so崩溃了，再研究堆栈发现是libsqilte引起的，那么具体是哪一个函数崩溃了呢？这里面没有信息。另外内核加载动态库是动态加载的，就算我们反汇编出来libc.so和libsqlite.so，符号表也没有办法和log中地址对应上，除非我们能知道内核加载libc.so和libsqlite.so的
基地址，这样我们就可以通过偏移找到相应的函数了。很幸运，Android确实规定了系统中的大部分库的内核加载地址。文件的位置在build/core 下，有对应平台的map文件，比如：Arm平台文件名叫做prelink-linux- arm.map，Mips平台叫做prelink-linux-mips.map。我是在Mips平台出的问题，所以应该用prelink-linux- mips.map文件来定位。文件内容如下：
# 0x7F100000 - 0x7FFF0000 Thread 0 stack

# 0x7F000000 - 0x7F0FFFFF Linker

# 0x70000000 - 0x7EFFFFFF Prelinked System Libraries

# 0x60000000 - 0x6FFFFFFF Prelinked App Libraries

# 0x50000000 - 0x5FFFFFFF Non-prelinked Libraries

# 0x40000000 - 0x4FFFFFFF mmap'd stuff

# 0x10000000 - 0x3FFFFFFF Thread Stacks

# 0x00080000 - 0x0FFFFFFF .text / .data / heap

# core system libraries

libdl.so 0x7EFF0000

libc.so 0x7EF00000

libstdc++.so 0x7EEF0000

libm.so 0x7EE90000

liblog.so 0x7EE80000

libcutils.so 0x7EE00000

libthread_db.so 0x7ED80000

libz.so 0x7ED00000

libevent.so 0x7EC80000

libssl.so 0x7EC00000

libcrypto.so 0x7EA00000

libffi.so 0x7E980000

libsysutils.so 0x7E900000

# bluetooth

liba2dp.so 0x7E780000

audio.so 0x7E700000

input.so 0x7E680000

libhcid.so 0x7E600000

libbluedroid.so 0x7E580000

libbluetooth.so 0x7E500000

libdbus.so 0x7E400000

# extended system libraries

libril.so 0x7E300000

libreference-ril.so 0x7E000000

libwpa_client.so 0x7DC00000

libnetutils.so 0x7DB00000

# core dalvik runtime support

libandroid_servers.so 0x7D900000

#libicudata.so 0x7D700000

libicuuc.so 0x7D500000

libicui18n.so 0x7D380000

libandroid_runtime.so 0x7D2a0000

libnativehelper.so 0x7D200000

libdvm-MIPS.so 0x7D180000

libdvm.so 0x7D000000

# graphics

libpixelflinger.so 0x7CF00000

libsurfaceflinger.so 0x7CD00000

libagl.so 0x7CC00000

libGLESv1_CM.so 0x7CB00000

libGLESv2.so 0x7CA00000

libOpenVG_CM.so 0x7C900000

libOpenVGU_CM.so 0x7C800000

libEGL.so 0x7C700000

libexif.so 0x7C500000

libui.so 0x7C400000

libsgl.so 0x7C000000

# audio

libspeech.so 0x7BA00000

libaudio.so 0x7B900000

libsonivox.so 0x7B800000

libsoundpool.so 0x7B700000

libvorbisidec.so 0x7B600000

libmedia_jni.so 0x7B500000

libmediaplayerservice.so 0x7B480000

libmedia.so 0x7B400000

libFFTEm.so 0x7B300000

libaudioflinger.so 0x7B200000

# assorted system libraries

libsqlite.so 0x7B100000

libexpat.so 0x7B000000

libwebcore.so 0x7A000000

libutils.so 0x79D00000

libcameraservice.so 0x79C80000

libhardware.so 0x79C70000

libhardware_legacy.so 0x79C00000

libapp_process.so 0x79B00000

libsystem_server.so 0x79A00000

libime.so 0x79800000

libgps.so 0x79700000

libcamera.so 0x79680000

libqcamera.so 0x79400000

# pv libraries

libpvasf.so 0x79200000

libpvasfreg.so 0x79100000

libomx_sharedlibrary.so 0x790e0000

libopencore_download.so 0x79000000

libopencore_downloadreg.so 0x78f00000

libopencore_net_support.so 0x78e00000

libopencore_rtsp.so 0x78d00000

libopencore_rtspreg.so 0x78c00000

libopencore_author.so 0x78a00000

libomx_aacdec_sharedlibrary.so 0x789c0000

libomx_amrdec_sharedlibrary.so 0x78990000

libomx_amrenc_sharedlibrary.so 0x78970000

libomx_avcdec_sharedlibrary.so 0x78958000

libomx_m4vdec_sharedlibrary.so 0x78930000

libomx_m4venc_sharedlibrary.so 0x788f0000

libomx_mp3dec_sharedlibrary.so 0x788d0000

libopencore_mp4local.so 0x78800000

libopencore_mp4localreg.so 0x78700000

libopencore_player.so 0x78400000

# opencore hardware support

libmm-adspsvc.so 0x783c0000

libOmxCore.so 0x783a0000

libOmxMpeg4Dec.so 0x78370000

libOmxH264Dec.so 0x78340000

libOmxVidEnc.so 0x78310000

libopencorehw.so 0x78300000

libopencore_common.so 0x78180000

#libqcomm_omx.so 0xA5A00000

# libraries for specific apps or temporary libraries

libcam_ipl.so 0x6F000000

libwbxml.so 0x6E800000

libwbxml_jni.so 0x6E400000

libxml2wbxml.so 0x6E000000

libaes.so 0x6DC00000

libdrm1.so 0x6D800000

libdrm1_jni.so 0x6D400000

libwapcore.so 0x6D000000

libstreetview.so 0x6CC00000

libwapbrowsertest.so 0x6C800000

libminiglobe.so 0x6C400000

libearth.so 0x6C000000

libembunit.so 0x6BC00000

libneon.so 0x6B800000

libjni_example.so 0x6B400000

libjni_load_test.so 0x6B000000

libjni_lib_test.so 0x6AC00000

librunperf.so 0x6A800000

libctest.so 0x6A700000

libUAPI_jni.so 0x6A500000

librpc.so 0x6A400000

libtrace_test.so 0x6A300000

libsrec_jni.so 0x6A200000

libcerttool_jni.so 0x6A100000

libacc.so 0x6A000000

libbinder.so 0x69F00000

libskia.so 0x69000000

libGLES_android.so 0x68800000

libRS.so 0x68000000

libaudiopolicygeneric.so 0x67c00000

librs_jni.so 0x67800000

# Sigma Designs libraries

libcore.so 0x61400000

libdisplay.so 0x61000000

libdrm.so 0x60c00000

libhw.so 0x60800000

libplayback.so 0x60000000

从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0×7EF00000，libsqlite.so加载到 0×7B100000。我们可以对照一下Crash的log信息也对应的上，说明这个文件在Android加载过程中起了作用。

下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具，我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。
mips-linux-gnu-objdump -dS libc.so > libc.dump

mips-linux-gnu-objdump -dS libsqlite.so > libsqlite.dump

这样就可以得到libc和libsqlite的符号表。然后通过符号表，Android加载动态库的基地址，log信息就可以定位到那个函数出问题了。本文就不具体讲了，怎样利用这个三个文件信息了。
一般情况下，Crash都不是Android源码的问题，最有可能的是内核有些模块没有进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。