當前位置:首頁 » 安卓系統 » 安卓addr2line在哪裡

安卓addr2line在哪裡

發布時間: 2022-05-15 00:36:54

㈠ 如何分析Android的Log

首先,讓我們看一看AndroidLog的格式。下面這段log是以所謂的long格式列印出來的。從前面Logcat的介紹中可以知道,long格式會把時間,標簽等作為單獨的一行顯示。

[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]

Start procnet.coollet.infzmreader:umengService_v1 for service
net.coollet.infzmreader/com.umeng.message.

UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}

[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]

Turning on JNI app bug workarounds fortarget SDK version 8...

[ 12-09 21:39:35.611 21745:21745D/AgooService ]

onCreate()

我們以第一行為例:12-09 是日期,21:39:35.510是時間396是進程號,416是線程號;I代表log優先順序,ActivityManager是log標簽。

在應用開發中,這些信息的作用可能不是很大。但是在系統開發中,這些都是很重要的輔助信息。開發工程師分析的log很多都是由測試工程師抓取的,所以可能有些log根本就不是當時出錯的log。如果出現這種情況,無論你怎麼分析都不太可能得出正確的結論。如何能最大限度的避免這種情況呢?筆者就要求測試工程師報bug時必須填上bug發生的時間。這樣結合log里的時間戳信息就能大致判斷是否是發生錯誤時的log。而且根據測試工程師提供的bug發生時間點,開發工程師可以在長長的log信息中快速的定位錯誤的位置,縮小分析的范圍。

同時我們也要注意,時間信息在log分析中可能被錯誤的使用。例如:在分析多線程相關的問題時,我們有時需要根據兩段不同線程中log語句執行的先後順序來判斷錯誤發生的原因,但是我們不能以兩段log在log文件中出現的先後做為判斷的條件,這是因為在小段時間內兩個線程輸出log的先後是隨機的,log列印的先後順序並不完全等同於執行的順序。那麼我們是否能以log的時間戳來判斷呢?同樣是不可以,因為這個時間戳實際上是系統列印輸出log時的時間,並不是調用log函數時的時間。遇到這種情況唯一的辦法是在輸出log前,調用系統時間函數獲取當時時間,然後再通過log信息列印輸出。這樣雖然麻煩一點,但是只有這樣取得的時間才是可靠的,才能做為我們判斷的依據。

另外一種誤用log中時間戳的情況是用它來分析程序的性能。一個有多年工作經驗的工程師拿著他的性能分析結果給筆者看,但是筆者對這份和實際情況相差很遠的報告表示懷疑,於是詢問這位工程師是如何得出結論的。他的回答讓筆者很驚訝,他計算所採用的數據就是log信息前面的時間戳。前面我們已經講過,log前面時間戳和調用log函數的時間並不相同,這是由於系統緩沖log信息引起的,而且這兩個時間的時間差並不固定。所以用log信息前附帶的時間戳來計算兩段log間代碼的性能會有比較大的誤差。正確的方法還是上面提到的:在程序中獲取系統時間然後列印輸出,利用我們列印的時間來計算所花費的時間。

了解了時間,我們再談談進程Id和線程Id,它們也是分析log時很重要的依據。我們看到的log文件,不同進程的log信息實際上是混雜在一起輸出的,這給我們分析log帶來了很大的麻煩。有時即使是一個函數內的兩條相鄰的log,也會出現不同進程的log交替輸出的情況,也就是A進程的第一條log後面跟著的是B進程的第二條log,對於這樣的組合如果不細心分析,就很容易得出錯誤的結論。這時一定要仔細看log前面的進程Id,把相同Id的log放到一起看。

不同進程的log有這樣的問題,不同的線程輸出的log當然也存在著相同的問題。Logcat加上-vthread就能列印出線程Id。但是有一點也要引起注意,就是Android的線程Id和我們平時所講的linux線程Id並不完全等同。首先,在Android系統中,C++層使用的Linux獲取線程Id的函數gettid()是不能得到線程Id的,調用gettid()實際上返回的是進程Id。作為替代,我們可以調用pthread_self()得到一個唯一的值來標示當前的native線程。Android也提供了一個函數androidGetThreaId()來獲取線程Id,這個函數實際上就是在調用pthread_self函數。但是在java層線程Id又是另外一個值,Java層的線程Id是通過調用Thread的getId方法得到的,這個方法的返回值實際上來自Android在每個進程的java層中維護的一個全局變數,所以這個值和C++層所獲得的值並不相同。這也是我們分析log時要注意的問題,如果是Java層線程Id,一般值會比較小,幾百左右;如果是C++層的線程,值會比較大。在前裡面的log樣本中,就能很容易的看出,第一條log是Jave層輸出的log,第二條是native層輸出的。明白了這些,我們在分析log時就不要看見兩段log前面的線程Id不相同就得出是兩個不同線程log的簡單結論,還要注意Jave層和native層的區別,這樣才能防止被誤導。

AndroidLog的優先順序在列印輸出時會被轉換成V,I,D,W,E等簡單的字元標記。在做系統log分析時,我們很難把一個log文件從頭看到尾,都是利用搜索工具來查找出錯的標記。比如搜索「E/」來看看有沒有指示錯誤的log。所以如果參與系統開發的每個工程師都能遵守Android定義的優先順序含義來輸出log,這會讓我們繁重的log分析工作變得相對輕鬆些。

Android比較常見的嚴重問題有兩大類,一是程序發生崩潰;二是產生了ANR。程序崩潰和ANR既可能發生在java層,也可能發生在native層。如果問題發生在java層,出錯的原因一般比較容易定位。如果是native層的問題,在很多情況下,解決問題就不是那麼的容易了。我們先看一個java層的崩潰例子:

I/ActivityManager( 396): Start proccom.test.crash for activity com.test.crash/.MainActivity:
pid=1760 uid=10065 gids={50065, 1028}

D/AndroidRuntime( 1760): Shutting downVM

W/dalvikvm( 1760): threadid=1: threadexiting with uncaught exception(group=0x40c38930)

E/AndroidRuntime( 1760): FATALEXCEPTION: main

E/AndroidRuntime( 1760):java.lang.RuntimeException: Unable to start activityComponentInfo
{com.test.crash/com.test.crash.MainActivity}:java.lang.NullPointerException

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2180)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2230)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.access$600(ActivityThread.java:141)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:1234)

E/AndroidRuntime( 1760): atandroid.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 1760): atandroid.os.Looper.loop(Looper.java:137)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.main(ActivityThread.java:5050)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invokeNative(NativeMethod)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:793)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)

E/AndroidRuntime( 1760): atdalvik.system.NativeStart.main(NativeMethod)

E/AndroidRuntime( 1760): Caused by:java.lang.NullPointerException

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.setViewText(MainActivity.java:29)

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.onCreate(MainActivity.java:17)

E/AndroidRuntime( 1760): atandroid.app.Activity.performCreate(Activity.java:5104)

E/AndroidRuntime( 1760): atandroid.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1080)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2144)

E/AndroidRuntime( 1760): ... 11more

I/Process ( 1760): Sending signal.PID: 1760 SIG: 9

W/ActivityManager( 396): Force finishing activitycom.test.crash/.MainActivity

Jave層的代碼發生crash問題時,系統往往會列印出很詳細的出錯信息。比如上面這個例子,不但給出了出錯的原因,還有出錯的文件和行數。根據這些信息,我們會很容易的定位問題所在。native層的crash雖然也有棧log信息輸出,但是就不那麼容易看懂了。下面我們再看一個native層crash的例子:

F/libc ( 2102): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread2102 (testapp)

D/dalvikvm(26630):GC_FOR_ALLOC freed 604K, 11% free 11980K/13368K, paused 36ms, total36ms

I/dalvikvm-heap(26630):Grow heap (frag case) to 11.831MB for 102416-byteallocation

D/dalvikvm(26630):GC_FOR_ALLOC freed 1K, 11% free 12078K/13472K, paused 34ms, total34ms

I/DEBUG ( 127):*** *** *** *** *** *** *** *** *** *** *** *** *** *** ******

I/DEBUG ( 127):Build fingerprint:
'Android/full_maguro/maguro:4.2.2/JDQ39/eng.liuchao.20130619.201255:userdebug/test-keys'

I/DEBUG ( 127):Revision: '9'

I/DEBUG ( 127):pid: 2102, tid: 2102, name: testapp >>>./testapp <<<
I/DEBUG ( 127):signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr00000000

I/DEBUG ( 127): r0 00000020 r173696874 r2 400ff520 r300000000

I/DEBUG ( 127): r4 400ff469 r5beb4ab24 r6 00000001 r7beb4ab2c

I/DEBUG ( 127): r8 00000000 r900000000 sl 00000000 fpbeb4ab1c

I/DEBUG ( 127): ip 4009b5dc spbeb4aae8 lr 400ff46f pc400ff45e cpsr 60000030

I/DEBUG ( 127): d0 000000004108dae8 d1 4108ced84108cec8

I/DEBUG ( 127): d2 4108cef84108cee8 d3 4108cf184108cf08

I/DEBUG ( 127): d4 4108c5a84108c598 d5 4108ca084108c5b8

I/DEBUG ( 127): d6 4108ce684108ce58 d7 4108ce884108ce78

I/DEBUG ( 127): d8 0000000000000000 d9 0000000000000000

I/DEBUG ( 127): d10 0000000000000000 d110000000000000000

I/DEBUG ( 127): d120000000000000000 d130000000000000000

I/DEBUG ( 127): d14 0000000000000000 d150000000000000000

I/DEBUG ( 127): d16 c1dcf7c087fec8b4 d173f50624dd2f1a9fc

I/DEBUG ( 127): d18 41c7b1ac89800000 d190000000000000000

I/DEBUG ( 127): d20 0000000000000000 d210000000000000000

I/DEBUG ( 127): d22 0000000000000000 d230000000000000000

I/DEBUG ( 127): d24 0000000000000000 d250000000000000000

I/DEBUG ( 127): d26 0000000000000000 d270000000000000000

I/DEBUG ( 127): d28 0000000000000000 d290000000000000000

I/DEBUG ( 127): d30 0000000000000000 d310000000000000000

I/DEBUG ( 127): scr 00000010

I/DEBUG ( 127):

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

I/DEBUG ( 127):

I/DEBUG ( 127):stack:

I/DEBUG ( 127): beb4aaa8 000000c8
I/DEBUG ( 127): beb4aaac 00000000
I/DEBUG ( 127): beb4aab0 00000000
I/DEBUG ( 127): beb4aab4 401cbee0 /system/bin/linker

I/DEBUG ( 127): beb4aab8 00001000
I/DEBUG ( 127): beb4aabc 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac0 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac4 40100eac /system/bin/testapp

I/DEBUG ( 127): beb4aac8 00000000
I/DEBUG ( 127): beb4aacc 400ff469 /system/bin/testapp

I/DEBUG ( 127): beb4aad0 beb4ab24 [stack]

I/DEBUG ( 127): beb4aad4 00000001
I/DEBUG ( 127): beb4aad8 beb4ab2c [stack]

I/DEBUG ( 127): beb4aadc 00000000
I/DEBUG ( 127): beb4aae0 df0027ad
I/DEBUG ( 127): beb4aae4 00000000
I/DEBUG ( 127): #00 beb4aae8 00000000
I/DEBUG ( 127): ........ ........

I/DEBUG ( 127): #01 beb4aae8 00000000
I/DEBUG ( 127): beb4aaec 401e9721 /system/lib/libc.so (__libc_init+40)

I/DEBUG ( 127): #02 beb4aaf0 beb4ab08 [stack]

I/DEBUG ( 127): beb4aaf4 00000000
I/DEBUG ( 127): beb4aaf8 00000000
I/DEBUG ( 127): beb4aafc 00000000
I/DEBUG ( 127): beb4ab00 00000000
I/DEBUG ( 127): beb4ab04 400ff404 /system/bin/testapp

I/DEBUG ( 127):

這個log就不那麼容易懂了,但是還是能從中看出很多信息,讓我們一起來學習如何分析這種log。首先看下面這行:

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<
從這一行我們可以知道crash進程的pid和tid,前文我們已經提到過,Android調用gettid函數得到的實際是進程Id號,所以這里的pid和tid相同。知道進程號後我們可以往前翻翻log,看看該進程最後一次列印的log是什麼,這樣能縮小一點范圍。

接下來內容是進程名和啟動參數。再接下來的一行比較重要了,它告訴了我們從系統角度看,出錯的原因:

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是Linux定義的信號之一,含義是Invalidmemory reference,無效的內存引用。加上後面的「faultaddr 00000000」我們基本可以判定這是一個空指針導致的crash。當然這是筆者為了講解而特地製造的一個Crash的例子,比較容易判斷,大部分實際的例子可能就沒有那麼容易了。

再接下來的log列印出了cpu的所有寄存器的信息和堆棧的信息,這裡面最重要的是從堆棧中得到的backtrace信息:

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因為實際的運行系統里沒有符號信息,所以列印出的log里看不出文件名和行數。這就需要我們藉助編譯時留下的符號信息表來翻譯了。Android提供了一個工具可以來做這種翻譯工作:arm-eabi-addr2line,位於prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目錄下。用法很簡單:

#./arm-eabi-addr2line -f -eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

參數-f表示列印函數名;參數-e表示帶符號表的模塊路徑;最後是要轉換的地址。這條命令在筆者的編譯環境中得到的結果是:

memcpy /home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩餘三個地址翻譯如下:

main /home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat /home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用這些信息我們很快就能定位問題了。不過這樣手動一條一條的翻譯比較麻煩,筆者使用的是從網上找到的一個腳本,可以一次翻譯所有的行,有需要的讀者可以在網上找一找。

了解了如何分析普通的Log文件,下面讓我們再看看如何分析ANR的Log文件。

㈡ 如何定位Android NDK開發中遇到的錯誤法

Android NDK定義:
Android NDK 是在SDK前面又加上了「原生」二字,即Native Development Kit,因此又被Google稱為「NDK」。眾所周知,Android程序運行在Dalvik虛擬機中,NDK允許用戶使用類似C / C++之類的原生代碼語言執行部分程序。
常見的NDK類型異常會導致程序錯誤:
NDK編譯生成的。so文件作為程序的一部分,在運行發生異常時同樣會造成程序崩潰。
不同於Java代碼異常造成的程序崩潰,在NDK的異常發生時,程序在Android設備上都會立即退出,即通常所說的閃退,而不會彈出「程序xxx無響應,是否立即關閉」之類的提示框。
NDK是使用C/C++來進行開發的,熟悉C/C++的程序員都知道,指針和內存管理是最重要也是最容易出問題的地方,稍有不慎就會遇到諸如內存無效訪問、無效對象、內存泄露、堆棧溢出等常見的問題。
在程序的某個位置釋放了某個內存空間,而後在程序的其他位置試圖訪問該內存地址,這就會產生無效地址錯誤。
發現並解決NDK錯誤:
ndk-stack。
這個命令行工具包含在NDK工具的安裝目錄,和ndk-build及其他常用的一些NDK命令放在一起。根據Google官方文檔,NDK從r6版本開始提供ndk-stack命令。
使用addr2line和objmp命令。
這個方法適用於那些不滿足於上述ndk-stack的簡單用法,在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈,其中就包含了這兩個命令,只不過名字稍有變化,可以在NDK目錄的toolchains目錄下找到。
注意:以上提到的方法,只適合在開發測試期間,如果應用或游戲已經上線,而用戶經常反饋說崩潰、閃退,指望用戶收集信息定位問題幾乎是不可能的。這個時候,就需要用其他的手段來捕獲崩潰信息。

㈢ 如何定位Android NDK開發中遇到的錯誤

如果你看過logcat列印的NDK錯誤的日誌就會知道,我省略了後面很多的內容,很多人看到這么多密密麻麻的日誌就已經頭暈腦脹了,即使是很多資深的Android開發者,在面對NDK日誌時也大都默默地選擇了無視。
其實,只要你細心的查看,再配合Google 提供的工具,完全可以快速地准確定位出錯的代碼位置,這個工作我們稱之為「符號化」。需要注意的是,如果要對NDK錯誤進行符號化的工作,需要保留編譯過程中產生的包含符號表的so文件,這些文件一般保存在$PROJECT_PATH/obj/local/目錄下。
第一種方法:ndk-stack
這個命令行工具包含在NDK工具的安裝目錄,和ndk-build及其他常用的一些NDK命令放在一起,比如在我的電腦上,其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔,NDK從r6版本開始提供ndk-stack命令,如果你用的之前的版本,建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式
實時分析日誌
在運行程序的同時,使用adb獲取logcat日誌,並通過管道符輸出給ndk-stack,同時需要指定包含符號表的so文件位置;如果你的程序包含了多種CPU架構,在這里需求根據錯誤發生時的手機CPU類型,選擇不同的CPU架構目錄,如:

當崩潰發生時,會得到如下的信息:

我們重點看一下#03和#04,這兩行都是在我們自己生成的libhello-jni.so中的報錯信息,因此會發現如下關鍵信息:

回想一下我們的代碼,在JNI_OnLoad()函數中(第61行),我們調用了willCrash()函數;在willCrash()函數中(第69行),我們製造了一個錯誤。這些信息都被准確無誤的提取了出來!是不是非常簡單?
先獲取日誌再分析
這種方法其實和上面的方法沒有什麼大的區別,僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件,甚至可以在崩潰發生時,快速的將logcat日誌保存起來,然後再進行分析,比上面的方法稍微靈活一點,而且日誌可以留待以後繼續分析。

第二種方法:使用addr2line和objmp命令
這個方法適用於那些不滿足於上述ndk-stack的簡單用法,而喜歡刨根問底的程序員們,這兩個方法可以揭示ndk-stack命令的工作原理是什麼,盡管用起來稍微麻煩一點,但可以稍稍滿足一下程序員的好奇心。
先簡單說一下這兩個命令,在絕大部分的Linux發行版本中都能找到他們,如果你的操作系統是Linux,而你測試手機使用的是Intel x86系列,那麼你使用系統中自帶的命令就可以了。然而,如果僅僅是這樣,那麼絕大多數人要絕望了,因為恰恰大部分開發者使用的是Windows,而手機很有可能是armeabi系列。
在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈,其中就包含了這兩個命令,只不過名字稍有變化,你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例,如果我要找的是適用於armeabi架構的工具,那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp;位置在下面目錄中,後續介紹中將省略此位置:

假設你的電腦是Windows系統,CPU架構為mips,那麼你要的工具可能包含在一下目錄中:

接下來就讓我們來看看如何使用這兩個工具,下面具體介紹。
找到日誌中的關鍵函數指針
其實很簡單,就是找到backtrace信息中,屬於我們自己的so文件報錯的行。
首先要找到backtrace信息,有的手機會明確列印一行backtrace(比如我們這次使用的手機),那麼這一行下面的一系列以「#兩位數字 pc」開頭的行就是backtrace信息了。有時可能有的手機並不會列印一行backtrace,那麼只要找到一段以「#兩位數字 pc 」開頭的行,就可以了。

其次要找到屬於自己的so文件報錯的行,這就比較簡單了。找到這些行之後,記下這些行中的函數地址。

使用addr2line查找代碼位置
執行如下的命令,多個指針地址可以在一個命令中帶入,以空格隔開即可

結果如下:

從addr2line的結果就能看到,我們拿到了我們自己的錯誤代碼的調用關系和行數,在hello-jni.cpp的69行和61行(另外兩行因為使用的是標准函數,可以忽略掉),結果和ndk-stack是一致的,說明ndk-stack也是通過addr2line來獲取代碼位置的。

㈣ 如何使用arm-linux-androideabi-addr2line

1.將ndk中的arm-linux-androideabi-addr2line可執行文件的路徑加入配置文件~/.bashrc中,例如:
export PATH=$PATH:~/dlna/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin

2.使配置生效:source ~/.bashrc

3.使用工具。例如:arm-linux-androideabi-addr2line -C -f -e ~/workspace/DLNA/libs/armeabi/libctrlpt.so 0003deb4
其中,0003deb4為堆棧信息中pc的值。

android應用崩潰的調試方法
有兩種方法可以分析 crash 的堆棧信息
1 google提供了一個python腳本,可以從
http://code.google.com/p/android-ndk-stacktrace-analyzer/
下載這個python腳本,然後使用 adb logcat -d > logfile 導出 crash 的log,
使用 arm-eabi-objmp 位於build/prebuilt/linux-x86/arm-eabi-4.2.1/bin下面
把so或exe轉換成匯編代碼,如:arm-eabi-objmp -S mylib.so > mylib.asm,
使用腳本
python parse_stack.py <asm-file> <logcat-file>
2 直接使用NDK下面的arm-linux-androideabi-addr2line
(D:\android-ndk-r8\toolchains\arm-linux-
androideabi-4.4.3\prebuilt\windows\bin\arm-linux-androideabi-addr2line.exe)
例如:arm-linux-androideabi-addr2line -C -f -e libxxx.so 0x#####(address)

android調試工具addr2line使用補充
使用addr2line追蹤自有動態庫(so文件)的bug, 補充:
解決出現 ??:0 , 沒法展示源代碼行數的問題

在Android.mk 文件中:

Java代碼
LOCAL_CFLAGS
:=
-D__STDC_CONSTANT_MACROS
-Wl,-Map=test.map
-g

補充2個編譯參數 -Wl,-Map=test.map -g .
增加gcc警告和調試標志

arm-linux-androideabi-addr2line -C -f -e /項目目錄/obj/local/armeabi/libfaa_jni.so 0024362e

tip: 1,注意調試文件的位置在obj目錄下,並非libs目錄下生成的so文件
2,0024362e 為出錯的機制位置

還有:
在jni/目錄下增加Application.mk 文件, 修改為debug 模式,進行調試 APP_OPTIM := debug

㈤ addr2line,android,該怎麼解決

明顯:arm-linux-androideabi-g++找進入目錄:prebuilt/linux-x86/ccache/ccache prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/

看否文件或鏈接文件:

arm-linux-androideabi-addr2line arm-linux-androideabi-gprof
arm-linux-androideabi-ar arm-linux-androideabi-ld
arm-linux-androideabi-as arm-linux-androideabi-ld.bfd
arm-linux-androideabi-c++ arm-linux-androideabi-ld.gold
arm-linux-androideabi-c++filt arm-linux-androideabi-nm
arm-linux-androideabi-cpp arm-linux-androideabi-obj
arm-linux-androideabi-g++ arm-linux-androideabi-objmp
arm-linux-androideabi-gcc arm-linux-androideabi-ranlib
arm-linux-androideabi-gcc-4.4.3 arm-linux-androideabi-readelf
arm-linux-androideabi-gccbug arm-linux-androideabi-run
arm-linux-androideabi-gcov arm-linux-androideabi-size
arm-linux-androideabi-gdb arm-linux-androideabi-strings
arm-linux-androideabi-gdbtui arm-linux-androideabi-strip

特別看:arm-linux-androideabi-g++

若沒別(同事朋友邊拷份)份放若軟鏈接文件看看鏈接指向文件存存份放鏈接指向文件

㈥ 如何使用arm-linux-androideabi-addr2line 查看函數名

1.將ndk中的arm-Linux-androideabi-addr2line可執行文件的路徑加入配置文件~/.bashrc中,例如:
export PATH=$PATH:~/dlna/Android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin

2.使配置生效:source ~/.bashrc

3.使用工具。例如:arm-linux-androideabi-addr2line -C -f -e ~/workspace/DLNA/libs/armeabi/libctrlpt.so 0003deb4
其中,0003deb4為堆棧信息中pc的值。

㈦ 關於Android JNI 編程如何定位段錯誤的問題(addr2line的使用)求答案

今天在此總結一下:
1.普通的應用程序或者靜動態庫,如果你想用addr2line 來定位段錯誤出在哪一行,請記住在編譯它們的時候一定加上編譯選項 -g 它會生成symbols信息 在你的exe or lib 裡面。
2.NDK編譯生成靜動態庫就沒有必要在Android.mk的編譯選項裡面加-g了,應為ndk默認就會生成symbols,這個是我做實驗得出來的結論。你可以在與jni平行的一層目錄中找到libs 和 objs文件夾 在這兩個文件夾裡面分別可以找到程序運行需要的動態庫和含symbols信息的動態庫。
至於addr2line的使用方法 ,我在這里也啰嗦一句
addr2line -e xxxx.so [報段錯誤的地址] 庫就是地址後面跟的庫
就說這么多唄!

㈧ 如何在Android studio下調試ndk

1.Library Symbols (共享庫的符號)
ndk提供了一些工具可以供程序員直接獲取到出錯的文件,函數以及行數。 但是這部分工具都需要沒有去符號的共享庫(通常是放在main/obj/local/armeabi-v7a)。而main/libs/armeabi-v7a中的共享庫是去掉了符號的,所以直接從設備上抓下來的lib是不能夠通過工具來找到對應的符號(而且沒有去symbol的庫比去掉的空間佔用會大許多)。所以如果想要分析一份native crash,那麼unstripped lib幾乎不可缺少,但是即使是strip過的庫也同樣會包含少量的symbol。
2.Analyze Tools
即常用的輔助工具
1、addr2line ((ANDROID_NDK)\toolchains\arm-Linux-androideabi-4.7\prebuilt\windows\bin)
#通過backtrace一欄提供的地址查詢對應的符號,可以定位到文件,函數,行數.
Usage: addr2line –aCfe libs(trace_address)
2、ndk-stack (android-ndk-r8d\ndk-stack)
#相當於執行多次addr2line, 可以直接針對一份crash log使用,會輸出所有backtrace里地址對應的symbol
Usage: ndk-stack –sym (libdirectory)–mp(crash_log_file)

㈨ addr2line 定位so崩潰位置,該怎麼處理

要做的第一件事是:不要驚慌!修復崩潰並不費勁。如果你已經陣腳大亂,可能是你把情況想的太嚴重了。不要指望說句咒語就能讓bug奇跡般地消失,你需要採取有條不紊的方法,學會通過崩潰找出原因。首先是要在你的代碼中找出發生崩潰的確切位置:在哪個文件的哪一行。Xcode調試器會幫助你,不過你也要明白如何充分地運用它,這也正是本教程將向你展示的!

㈩ 關於Android JNI 編程如何定位段錯誤的問題(addr2line的使用)求答案

今天在此總結一下:
1.普通的應用程序或者靜動態庫,如果你想用addr2line
來定位段錯誤出在哪一行,請記住在編譯它們的時候一定加上編譯選項
-g
它會生成symbols信息
在你的exe
or
lib
裡面。
2.NDK編譯生成靜動態庫就沒有必要在Android.mk的編譯選項裡面加-g了,應為ndk默認就會生成symbols,這個是我做實驗得出來的結論。你可以在與jni平行的一層目錄中找到libs

objs文件夾
在這兩個文件夾裡面分別可以找到程序運行需要的動態庫和含symbols信息的動態庫。
至於addr2line的使用方法
,我在這里也啰嗦一句
addr2line
-e
xxxx.so
[報段錯誤的地址]
庫就是地址後面跟的庫
就說這么多唄!

熱點內容
ubuntu1204內核編譯 發布:2022-05-15 01:20:38 瀏覽:519
android廣播有幾種 發布:2022-05-15 01:17:35 瀏覽:990
糞壓縮器 發布:2022-05-15 01:16:54 瀏覽:755
ld3320用什麼編譯器 發布:2022-05-15 01:16:46 瀏覽:977
安卓版如何玩堡壘之夜 發布:2022-05-15 01:16:30 瀏覽:269
我的世界什麼伺服器是創造的 發布:2022-05-15 01:16:29 瀏覽:278
安卓手機微信怎麼折疊置頂 發布:2022-05-15 01:14:58 瀏覽:380
雲伺服器運行視頻優化軟體 發布:2022-05-15 01:12:56 瀏覽:835
hive壓縮格式 發布:2022-05-15 01:12:03 瀏覽:881
sqlitesql腳本 發布:2022-05-15 01:11:42 瀏覽:451