backtrace:
#00 pc 0003a428 /system/lib/libc.so (tgkill+12)
#01 pc 000181e3 /system/lib/libc.so (pthread_kill+66)
#02 pc 00018deb /system/lib/libc.so (raise+10)
#03 pc 0001563f /system/lib/libc.so (__libc_android_abort+34)
#04 pc 00013c30 /system/lib/libc.so (abort+4)
#05 pc 002310fd /system/lib/libart.so (art::Runtime::Abort()+184)
#06 pc 0009f123 /system/lib/libart.so (art::LogMessage::~LogMessage()+2046)
#07 pc 00108a29 /system/lib/libart.so (art_heap_corruption(char const*)+140)
#08 pc 0010bb8d /system/lib/libart.so (mspace_bulk_free+772)
#09 pc 00145751 /system/lib/libart.so (art::gc::space::DlMallocSpace::FreeList(art::Thread*, unsigned int, art::mirror::Object**)+76)
#10 pc 00121a21 /system/lib/libart.so (art::gc::collector::MarkSweep::SweepArray(art::gc::accounting::AtomicStackart::mirror::Object*

使用addrline2解析backtrace
1.找到發生問題的so庫，如libc.so，把它放在android-5.1.1\prebuilts\gcc\linux-x86\aarch64\aarch64-linux-android-4.8\bin中
2.在linux伺服器上輸入命令
addr2line -C -e libc.so -f 0003a428
0003a428來自於#00 pc 0003a428 /system/lib/libc.so (tgkill+12)

一般情況下這樣使用是沒問題的，但是很多時候問題都發生在so庫即動態庫中就不能很好的打印出具體報錯的地方

舉個例子，要測試復現該bug時要先儲存下環境
1.在終端的/system/lib 中找到發生問題的so庫，如libc.so，儲存在linux伺服器上的android-5.1.1\prebuilts\gcc\linux-x86\aarch64\aarch64-linux-android-4.8\bin
2.終端上使用ps 找出so庫的程序id，一般就是app的程序，如2467，然後cd/proc/2467
cat maps |grep libc.so
顯示如下內容 把第一行的地址儲存下來
f7439000-f749f000 r-xp 00000000 b3:0d 41034 /system/lib/libc.so
f74a0000-f74a3000 r–p 00066000 b3:0d 41034 /system/lib/libc.so
f74a3000-f74a6000 rw-p 00069000 b3:0d 41034 /system/lib/libc.so

發生tombston後取出日誌，確認下tombstone的地址是否在f7439000-f749f000之間，如果是則用tombstopn與f7439000差的絕對值value
輸入命令addr2line -C -e libc.so -f value