Android：動態庫(.so)調試技巧

1、反彙編定位crash

　　①查看crash log:

　　　　

 

　　　　上圖已標出crash發生在 libdeflicker_gpu.so 庫中的 default_fail_func() 函數，可是 libdeflicker_gpu.so 是第三方動態庫，沒法分析代碼，因此退一步到外層的調用代碼查找問題。

　　　　連接  libdeflicker_gpu.so 的動態庫是 com.arcsoft.node.deflickergpu.so，由本身封裝層代碼生成，從代碼查找到調用了 libdeflicker_gpu.so 的接口函數 ADF_Preview_Process_FD，crash的時候寄存器的值保存了下來，上圖黃框所示。

 

　　②使用ndk objdump工具反彙編libdeflicker_gpu.so庫（注意32/64位庫的工具版本不一樣）：

D:\Android\Sdk\ndk-bundle\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\aarch64-linux-android\bin\objdump.exe -d libdeflicker_gpu.so > objdump_libdeflicker.txt

　　　從保存的 objdump_libdeflicker.txt 文本中找到 ADF_Preview_Process_FD 函數：

　　　

 

 　　　可看到函數起始地址爲 056188（十六進制），crash地址爲 = 056188（十六進制） + 12（十進制） = 0x056194

　　　接着分析dump 文件可知，0056194處的指令是 stp    x29, x30, [sp,#176]，即把一對值x29和x30放到SP+176的地址，從函數的入口取值就發生了crash，說明傳入的參數有問題，通常是指針爲空或指向了非法內存致使。

　　　因此在調用層檢測傳入參數便可，好比是結構體，就把其中指針變量都打印出來確認一下是否有效。若是外層參數都沒問題，就說明第三方庫內部的bug，須要找提供庫的人進行排查。

　技巧總結：先在crash彙編指令附近找特殊指令，如mla 乘加指令、64位乘法、移位等出現次數較少的指令，大體定位下crash範圍，而後逐行分析彙編找到精確的c/c++代碼位置。

 

 

2、查看動態庫符號表

（1）nm -D xxx.so

（2）readelf -s xxx.so