Android下打印調試堆棧方法

打印堆棧是調試的常用方法，一般在系統異常時，我們可以將異常情況下的堆棧打印出來，這樣十分方便錯誤查找。實際上還有另外一個非常有用的功能：分析代碼的行爲。android代碼太過龐大複雜了，完全的靜態分析經常是無從下手，因此通過打印堆棧的動態分析也十分必要。

Android打印堆棧的方法，簡單歸類一下

1. zygote的堆棧dump

實際上這個可以同時dump java線程及native線程的堆棧，對於java線程，java堆棧和native堆棧都可以得到。

使用方法很簡單，直接在adb shell或串口中輸入：

[plain]view
plain copy

kill -3 <pid>  

輸出的trace會保存在 /data/anr/traces.txt文件中。這個需要注意，如果沒有 /data/anr/這個目錄或/data/anr/traces.txt這個文件，需要手工創建一下，並設置好讀寫權限。

如果需要在代碼中，更容易控制堆棧的輸出時機，可以用以下命令獲取zygote的core dump:

[java]view
plain copy

Process.sendSignal(pid, Process.SIGNAL_QUIT);  

原理和命令行是一樣的。

不過需要注意兩點：

adb shell可能會沒有權限，需要root。
android 4.2中關閉了native thread的堆棧打印，詳見 dalvik/vm/Thread.cpp的dumpNativeThread方法：

[cpp]view
plain copy

dvmPrintDebugMessage(target,  

    "\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",  

    name, tid, getpriority(PRIO_PROCESS, tid),  

    schedStats.policy, schedStats.priority, schedStats.group);  

dumpSchedStat(target, tid);  

// Temporarily disabled collecting native stacks from non-Dalvik  

// threads because sometimes they misbehave.  

//dvmDumpNativeStack(target, tid);

Native堆棧的打印被關掉了！不過對於大多數情況，可以直接將這個註釋打開。

2. debuggerd的堆棧dump

debuggerd是android的一個daemon進程，負責在進程異常出錯時，將進程的運行時信息dump出來供分析。debuggerd生成的coredump數據是以文本形式呈現，被保存在 /data/tombstone/ 目錄下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10個文件，當超過10個時，會覆蓋重寫最早生成的文件。從4.2版本開始，debuggerd同時也是一個實用工具：可以在不中斷進程執行的情況下打印當前進程的native堆棧。使用方法是:

[plain]view
plain copy

debuggerd -b <pid>  

這可以協助我們分析進程執行行爲，但最最有用的地方是：它可以非常簡單的定位到native進程中鎖死或錯誤邏輯引起的死循環的代碼位置。

3. java代碼中打印堆棧

Java代碼打印堆棧比較簡單，堆棧信息獲取和輸出，都可以通過Throwable類的方法實現。目前通用的做法是在java進程出現需要注意的異常時，打印堆棧，然後再決定退出或挽救。通常的方法是使用exception的printStackTrace()方法：

[java]view
plain copy

try {  

 ...  

} catch (RemoteException e) {  

  e.printStackTrace();  

  ...  

}

當然也可以只打印堆棧不退出，這樣就比較方便分析代碼的動態運行情況。Java代碼中插入堆棧打印的方法如下：

[java]view
plain copy

Log.d(TAG,Log.getStackTraceString(new Throwable()));  

4. C++代碼中打印堆棧

C++也是支持異常處理的，異常處理庫中，已經包含了獲取backtrace的接口，Android也是利用這個接口來打印堆棧信息的。在Android的C++中，已經集成了一個工具類CallStack，在libutils.so中。使用方法：

[cpp]view
plain copy

#include <utils/CallStack.h>  

...  

CallStack stack;  

stack.update();  

stack.dump();

使用方式比較簡單。目前Andoid4.2版本已經將相關信息解析的很到位，符號表查找，demangle，偏移位置校正都做好了。

[plain]view
plain copy

5. C代碼中打印堆棧

C代碼，尤其是底層C庫，想要看到調用的堆棧信息，還是比較麻煩的。 CallStack肯定是不能用，一是因爲其實C++寫的，需要重新封裝才能在C中使用，二是底層庫反調上層庫的函數，會造成鏈接器循環依賴而無法鏈接。不過也不是沒有辦法，可以通過android工具類CallStack實現中使用的unwind調用及符號解析函數來處理。

這裏需要注意的是，爲解決鏈接問題，最好使用dlopen方式，查找需要用到的接口再直接調用，這樣會比較簡單。如下爲相關的實現代碼，只需要在要打印的文件中插入此部分代碼，然後調用getCallStack()即可，無需包含太多的頭文件和修改Android.mk文件：

[cpp]view
plain copy

#define MAX_DEPTH                       31  

#define MAX_BACKTRACE_LINE_LENGTH   800  

#define PATH "/system/lib/libcorkscrew.so"  

typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);  

typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);  

typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);  

static void *gHandle = NULL;  

static int getCallStack(void){  

    ssize_t i = 0;  

    ssize_t result = 0;  

    ssize_t count;  

    backtrace_frame_t mStack[MAX_DEPTH];  

    backtrace_symbol_t symbols[MAX_DEPTH];  

    unwindFn unwind_backtrace = NULL;  

    unwindSymbFn get_backtrace_symbols = NULL;  

    unwindSymbFreeFn free_backtrace_symbols = NULL;  

    // open the so.  

    if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);  

    // get the interface for unwind and symbol analyse  

    if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");  

    if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");  

    if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");  

    if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols  ){  

        ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",  

            gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );  

        return result;  

    }  

    count= unwind_backtrace(mStack, 1, MAX_DEPTH);  

    get_backtrace_symbols(mStack, count, symbols);  

    for (i = 0; i < count; i++) {  

        char line[MAX_BACKTRACE_LINE_LENGTH];  

        const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";  

        const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;  

        size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;  

        if (symbolName) {  

            uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;  

            if (pc_offset) {  

                snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d  pc %08x  %.*s (%.*s+%u)",  

                        i, symbols[i].relative_pc, fieldWidth, mapName,  

                        fieldWidth, symbolName, pc_offset);  

            } else {  

                snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d  pc %08x  %.*s (%.*s)",  

                        i, symbols[i].relative_pc, fieldWidth, mapName,  

                        fieldWidth, symbolName);  

            }  

        } else {  

            snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d  pc %08x  %.*s",  

                    i, symbols[i].relative_pc, fieldWidth, mapName);  

        }  

        ALOGD("%s", line);  

    }  

    free_backtrace_symbols(symbols, count);  

    return result;  

}

對sched_policy.c的堆棧調用分析如下,注意具體是否要打印，在哪裏打印，還可以通過pid、uid、property等來控制一下，這樣就不會被淹死在trace的汪洋大海中。

[plain]view
plain copy

D/SchedPolicy( 1350): #00  pc 0000676c  /system/lib/libcutils.so  

D/SchedPolicy( 1350): #01  pc 00006b3a  /system/lib/libcutils.so (set_sched_policy+49)  

D/SchedPolicy( 1350): #02  pc 00010e82  /system/lib/libutils.so (androidSetThreadPriority+61)  

D/SchedPolicy( 1350): #03  pc 00068104  /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)  

D/SchedPolicy( 1350): #04  pc 0001e510  /system/lib/libdvm.so (dvmPlatformInvoke+112)  

D/SchedPolicy( 1350): #05  pc 0004d6aa  /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)  

D/SchedPolicy( 1350): #06  pc 00027920  /system/lib/libdvm.so  

D/SchedPolicy( 1350): #07  pc 0002b7fc  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)  

D/SchedPolicy( 1350): #08  pc 00060c30  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)  

D/SchedPolicy( 1350): #09  pc 0004cd34  /system/lib/libdvm.so  

D/SchedPolicy( 1350): #10  pc 00049382  /system/lib/libandroid_runtime.so  

D/SchedPolicy( 1350): #11  pc 00065e52  /system/lib/libandroid_runtime.so  

D/SchedPolicy( 1350): #12  pc 0001435e  /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)  

D/SchedPolicy( 1350): #13  pc 00016f5a  /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)  

D/SchedPolicy( 1350): #14  pc 00017380  /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)  

D/SchedPolicy( 1350): #15  pc 0001b160  /system/lib/libbinder.so  

D/SchedPolicy( 1350): #16  pc 00011264  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)  

D/SchedPolicy( 1350): #17  pc 000469bc  /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)  

D/SchedPolicy( 1350): #18  pc 00010dca  /system/lib/libutils.so  

D/SchedPolicy( 1350): #19  pc 0000e3d8  /system/lib/libc.so (__thread_entry+72)  

D/SchedPolicy( 1350): #20  pc 0000dac4  /system/lib/libc.so (pthread_create+160)  

D/SchedPolicy( 1350): #00  pc 0000676c  /system/lib/libcutils.so  

D/SchedPolicy( 1350): #01  pc 00006b3a  /system/lib/libcutils.so (set_sched_policy+49)  

D/SchedPolicy( 1350): #02  pc 00016f26  /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)  

D/SchedPolicy( 1350): #03  pc 00017380  /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)  

D/SchedPolicy( 1350): #04  pc 0001b160  /system/lib/libbinder.so  

D/SchedPolicy( 1350): #05  pc 00011264  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)  

D/SchedPolicy( 1350): #06  pc 000469bc  /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)  

D/SchedPolicy( 1350): #07  pc 00010dca  /system/lib/libutils.so  

D/SchedPolicy( 1350): #08  pc 0000e3d8  /system/lib/libc.so (__thread_entry+72)  

D/SchedPolicy( 1350): #09  pc 0000dac4  /system/lib/libc.so (pthread_create+160)

6. 其它堆棧信息查詢

第二部分：strace工具使用

android 調試利器之 strace

strace 是linux下的調試利器；debug居家必備

strace可以跟蹤所有的系統調用，打印系統調用的參數和返回值； strace還可以指定跟蹤子線程/子進程，這是調試多線程程序必須的；

andriod 使用了linux操作系統，strace當然是好用的；

strace本身不依賴於系統，從一個機器拷貝到另一個機器直接能用；可以看到，strace 只依賴三個最基本的庫：

> readelf -a strace | grep NEEDED
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libm.so]

strace一般在/system/xbin/或者/system/bin/下；如果沒有呢，可以自己編譯一個，或者從其它android手機拷貝一份

linux上，strace一般有兩種用法：

a. strace <elf_file> 啓動程序的同時，用strace跟蹤；

b. strace -p pid 對於已經啓動的程序，通過-p參數可以attach上去跟蹤之後的執行流程；

android上使用strace有一點特殊，android上所有android application都是通過zygote fork出來的；(這是android的一大特點，即既節約內存，又能加快程序啓動時間，這裏不展開）

所有android application進程的父親都是zygote；

strace <elf_file> 顯然對不能用來跟蹤android application.（因爲它們都是fork來的）

我們可以使用strace的特性：a) attach到現有進程，b) 允許跟蹤子進程；

做法就是跟蹤zygote和它的兒子；

　　先得到zygote的pid，再執行 strace -f -p <pid_of_zygote>，然後啓動要跟蹤調試的程序；　

　　其中-f 代表跟蹤子進程；而且是之後生成的子進程，之前已經運行起來的android application不會被跟蹤到；

可以用一條命令包括前兩部：

　　strace -f -p `ps | grep zygote | awk '{print $2}'`

就是這麼簡單，debug的android程序員慢慢享用吧

Android下打印調試堆棧方法

selinux-實現

WINDOWS下加速 PYTHON PIP 安裝速度

selinux-概覽

ubuntu 19.10 electron 安裝，環境配置

selinux-驗證

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結