簡介這份資源面向在高通8155p平臺上進行QNXAndroid9雙系統(tǒng)開發(fā)的工程師聚焦于開啟ASANAddressSanitizer以定位Native層內存越界、泄漏等疑難問題。包內同時提供Android.mk與Android.bp兩套構建腳本示例覆蓋libAsanDebug、asan_debugd及其vnd變體、libclang_rt.asan運行時庫等模塊幫助開發(fā)者解決因構建配置不當導致ASAN無法使能、編譯報錯等常見障礙。資源共18個文件包含4個mk、4個bp構建腳本4個cpp源碼2個so預編譯庫2個h頭文件及2個mk~備份文件壓縮包約1.21MB結構清晰便于對照移植。目前已有1994人學習下載適合不熟悉Android.mk與Android.bp編寫、或反復遭遇編譯問題的開發(fā)者參考可快速掌握ASAN在車機雙系統(tǒng)環(huán)境下的集成方式與排錯思路。1. 高通8155p上QNXAndroid9雙系統(tǒng)ASAN到底能幫你抓到什么在高通8155p這類座艙平臺上QNX負責儀表與安全域Android9跑IVI應用兩邊通過Hypervisor共享內存、GPU和音頻通道。這種架構下最讓人頭疼的不是崩潰而是那種“偶發(fā)花屏、隨機重啟、日志里什么都沒有”的內存問題。ASANAddressSanitizer就是用來把這類玄學問題變成可定位堆棧的利器。它能在運行時檢測越界讀寫、釋放后使用、雙重釋放、內存泄漏等直接告訴你哪一行代碼踩了哪塊內存。本文面向的是在8155p上做Android9系統(tǒng)開發(fā)、需要開啟ASAN定位native內存問題的工程師。不管你的模塊用的是Android.mk還是Android.bp核心思路一致讓目標模塊帶上ASAN運行時并在QNXAndroid雙系統(tǒng)環(huán)境下正確加載。下面從原理到落地一步步拆。2. ASAN在Android9上的編譯鏈路從Android.mk到Android.bp2.1 為什么Android9的ASAN不能直接照搬高版本做法Android9API 28的編譯系統(tǒng)正處于Android.mk向Android.bp過渡的階段ASAN的支持方式和Android10以后有明顯差異。高版本上你可以在Android.bp里寫sanitize: { address: true }但在Android9的Soong里這個字段雖然存在對部分模塊類型支持并不完整尤其是涉及JNI、HAL和可執(zhí)行文件時。更穩(wěn)妥的做法是走LOCAL_SANITIZE : address這條老路或者用全局開關SANITIZE_TARGETaddress做整包構建。但整包ASAN在8155p上不現(xiàn)實——QNX側不參與Android構建Android側全量ASAN會導致鏡像巨大、啟動極慢Hypervisor分區(qū)根本放不下。所以實際落地一定是按模塊開啟只對懷疑有內存問題的native庫或可執(zhí)行文件做ASAN插樁。另一個坑是Android9默認的ASAN運行時庫路徑。libclang_rt.asan-aarch64-android.so需要和你的模塊一起推到設備上并且要在init階段通過LD_PRELOAD或者鏈接依賴的方式加載。如果只編譯不部署運行時運行時會直接報ASAN: failed to load runtime日志里只有一行很容易被忽略。2.2 Android.mk模塊開啟ASAN的最小改動假設你有一個native可執(zhí)行文件或共享庫用Android.mk管理。最小改動是在模塊定義里加三行# Android.mk 中為單個模塊開啟ASAN LOCAL_PATH : $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE : my_memory_test LOCAL_SRC_FILES : main.cpp LOCAL_SANITIZE : address LOCAL_SANITIZE_DIAG : address # 確保ASAN運行時被打包 LOCAL_REQUIRED_MODULES : libclang_rt.asan-aarch64-android include $(BUILD_EXECUTABLE)LOCAL_SANITIZE : address告訴編譯器插入ASAN插樁代碼LOCAL_SANITIZE_DIAG : address讓診斷信息更完整。LOCAL_REQUIRED_MODULES保證運行時庫被編進system分區(qū)。注意如果你的模塊是BUILD_SHARED_LIBRARY同樣適用但需要確認依賴它的上層模塊不會因為ASAN的符號沖突而崩潰。實際項目中我遇到過JNI庫開ASAN后Java層調用直接閃退原因是ASAN運行時和Android Runtime的malloc調試鉤子沖突解決辦法是在BoardConfig.mk里加MALLOC_DEBUG相關配置或者只對獨立可執(zhí)行文件開ASANJNI庫用LOCAL_SANITIZE的hwaddress替代——但Android9對HWASAN支持更弱所以多數(shù)時候還是回到獨立進程驗證。2.3 Android.bp模塊開啟ASAN的寫法與限制Android.bp在Android9里對ASAN的支持分兩種情況。對于cc_binary和cc_library可以寫// Android.bp 中為cc_binary開啟ASAN cc_binary { name: my_memory_test_bp, srcs: [main.cpp], sanitize: { address: true, diag: { address: true, }, }, required: [libclang_rt.asan-aarch64-android], }這段配置在Android9的Soong里能通過編譯但有一個隱藏問題required字段在部分Android9分支上不會自動把運行時庫加入system.img需要你在device.mk里手動加PRODUCT_PACKAGES libclang_rt.asan-aarch64-android。另外cc_library_shared開ASAN后如果被未開ASAN的模塊依賴鏈接階段會報undefined reference to __asan_init。這是因為ASAN插樁后的庫需要運行時符號而未插樁的模塊不會鏈接ASAN運行時。解決辦法是讓依賴鏈上的所有模塊都開ASAN或者把ASAN庫做成獨立可執(zhí)行文件通過dlopen加載。我一般會優(yōu)先選獨立可執(zhí)行文件方案因為對系統(tǒng)其他部分影響最小。2.4 編譯參數(shù)與運行時庫的對應關系ASAN在Android9上依賴幾個關鍵編譯參數(shù)-fsanitizeaddress、-fno-omit-frame-pointer、-fsanitize-recoveraddress可選。-fno-omit-frame-pointer必須加否則堆?；厮輹睅ㄎ痪却蟠蛘劭?。-fsanitize-recoveraddress讓ASAN在檢測到錯誤后繼續(xù)運行適合抓多個問題但默認建議關掉因為繼續(xù)運行可能掩蓋后續(xù)錯誤。運行時庫方面64位用libclang_rt.asan-aarch64-android.so32位用libclang_rt.asan-arm-android.so。8155p的Android9通常是64位為主但如果有32位兼容進程兩個都要推。推庫的位置一般是/system/lib64/和/system/lib/權限644selinux上下文要設為u:object_r:system_lib_file:s0否則init加載時會拒絕。3. QNXAndroid雙系統(tǒng)下ASAN的部署與觸發(fā)3.1 跨系統(tǒng)內存共享場景下ASAN的局限性QNX和Android通過Hypervisor共享內存時Android側的ASAN只能檢測Android進程內部的地址空間問題。如果內存越界發(fā)生在共享內存區(qū)域且寫壞的是QNX側的數(shù)據(jù)ASAN在Android側可能完全無感——因為那塊內存在Android的地址空間里是合法映射ASAN不會攔截。這種情況下需要配合QNX側的內存保護工具或者在共享內存邊界加哨兵值guard page來輔助判斷。實際項目中我遇到過Android側音頻服務寫共享內存越界導致QNX儀表進程崩潰但Android側ASAN日志干凈。最后是在共享內存分配時前后各加4KB guard page才定位到越界寫。所以ASAN不是萬能藥跨系統(tǒng)問題要結合邊界防護。3.2 把ASAN可執(zhí)行文件推上8155p并運行編譯出帶ASAN的可執(zhí)行文件后部署步驟如下# 推ASAN運行時庫和測試程序到設備 adb root adb remount adb push out/target/product/xxx/system/bin/my_memory_test /system/bin/ adb push prebuilts/clang/host/linux-x86/clang-xxx/lib64/libclang_rt.asan-aarch64-android.so /system/lib64/ adb shell chmod 644 /system/lib64/libclang_rt.asan-aarch64-android.so adb shell chmod 755 /system/bin/my_memory_test # 設置ASAN選項并運行 adb shell ASAN_OPTIONSdetect_leaks0:abort_on_error1:symbolize1 /system/bin/my_memory_testdetect_leaks0在Android9上建議關掉因為LeakSanitizer在Android的init進程環(huán)境下經常誤報而且需要ptrace權限selinux默認不允許。abort_on_error1讓ASAN檢測到錯誤立即abort方便抓core dump或tombstone。symbolize1讓ASAN嘗試符號化堆棧但需要llvm-symbolizer在設備上通常沒有所以實際符號化要在host側用ndk-stack或llvm-symbolizer離線做。運行后如果ASAN報錯日志會出現(xiàn)在logcat或stderr格式是ERROR: AddressSanitizer: heap-buffer-overflow on address...后面跟著調用棧。3.3 用wrap.sh在Android9上給JNI庫開ASAN如果問題出在JNI庫且不想重編整個APK可以用wrap.sh機制。在APK的lib/arm64-v8a/目錄下放一個wrap.sh#!/system/bin/sh # wrap.sh 為JNI庫加載ASAN運行時 HERE$(cd $(dirname $0) pwd) export LD_PRELOAD$HERE/libclang_rt.asan-aarch64-android.so export ASAN_OPTIONSdetect_leaks0:abort_on_error1 exec $同時把ASAN運行時庫放到同一目錄。wrap.sh需要可執(zhí)行權限且APK要設android:debuggabletrue。這個方案在Android9上對zygote啟動的進程有效但對init啟動的native服務無效。另外LD_PRELOAD加載ASAN運行時后所有malloc/free都會被攔截性能下降明顯只適合調試階段。我一般會在驗證完問題后立即移除wrap.sh避免影響正常功能。3.4 符號化堆棧從設備日志到代碼行ASAN在設備上輸出的堆棧通常是地址偏移沒有行號。符號化需要把out/target/product/xxx/symbols/下的帶符號文件拿到host側用llvm-symbolizer處理# 在host側符號化ASAN日志 llvm-symbolizer --objout/target/product/xxx/symbols/system/bin/my_memory_test asan_log.txt如果日志里是#0 0x1234 in my_func /path/to/file.cpp:42這種格式說明編譯時帶了-g且符號表沒被strip。Android9的release構建默認strip所以開ASAN的模塊要加LOCAL_STRIP_MODULE : falseAndroid.mk或strip: { none: true }Android.bp。否則符號化出來全是??。這個坑我踩過不止一次血淚經驗是開ASAN的同時一定關strip否則等于白抓。4. 避坑與常見問題排查4.1 ASAN報錯但堆棧全是問號現(xiàn)象ASAN日志里調用棧顯示#0 0x0000 in ??沒有任何函數(shù)名和行號。原因通常是編譯時strip了符號或者llvm-symbolizer找不到對應的帶符號文件。解決在模塊定義里關掉stripAndroid.mk加LOCAL_STRIP_MODULE : falseAndroid.bp加strip: { none: true }。同時確認out/target/product/xxx/symbols/下有對應模塊的未strip版本。如果還是不行檢查編譯時是否帶了-gAndroid9默認-g在eng構建下開啟userdebug下可能關閉需要手動加LOCAL_CFLAGS -g。4.2 開啟ASAN后模塊加載失敗報undefined symbol現(xiàn)象dlopen加載ASAN庫時失敗logcat報undefined reference to __asan_init或__asan_report_load8。原因是被ASAN插樁的庫依賴ASAN運行時符號但運行時庫沒有被正確加載。解決確保libclang_rt.asan-aarch64-android.so在/system/lib64/下且權限正確同時檢查依賴鏈上所有模塊是否都開了ASAN。如果只有部分模塊開未開的模塊調用開了ASAN的模塊時符號解析會失敗。最穩(wěn)妥的做法是讓ASAN模塊獨立成可執(zhí)行文件不與其他模塊共享鏈接。4.3 ASAN誤報LeakSanitizer導致進程被殺現(xiàn)象進程啟動后不久被init殺掉日志顯示LeakSanitizer: detected memory leaks。原因Android9的init進程和部分系統(tǒng)服務在啟動階段有大量一次性分配LeakSanitizer會把這些當成泄漏。解決在ASAN_OPTIONS里加detect_leaks0。如果確實需要查泄漏改用LSAN_OPTIONSsuppressions...加抑制文件把系統(tǒng)庫的分配排除掉。但Android9上LSAN對ptrace的依賴經常和selinux沖突所以多數(shù)時候直接關掉泄漏檢測只查越界和釋放后使用。4.4 雙系統(tǒng)共享內存越界ASAN抓不到現(xiàn)象QNX側進程崩潰Android側ASAN無任何輸出。原因越界寫發(fā)生在共享內存區(qū)域該區(qū)域在Android地址空間內是合法映射ASAN不攔截。解決在共享內存分配時前后加guard page或者用mprotect把邊界頁設為PROT_READ寫越界會觸發(fā)SIGSEGV再配合debuggerd抓tombstone。另外可以在共享內存結構里加magic number定期校驗發(fā)現(xiàn)被改寫就報錯。這個方案比ASAN更原始但在跨系統(tǒng)場景下更可靠。4.5 Android.bp的sanitize字段不生效現(xiàn)象在Android.bp里寫了sanitize: { address: true }但編譯出的二進制沒有ASAN插樁運行時也不報ASAN錯誤。原因Android9的Soong對部分模塊類型的sanitize支持不完整尤其是cc_library_shared和cc_binary在特定分支上會忽略該字段。解決改用LOCAL_SANITIZE的Android.mk寫法或者用全局SANITIZE_TARGETaddress構建后從out/里取插樁后的二進制手動推設備。驗證是否插樁成功可以用readelf -s看二進制里有沒有__asan_init符號有就是插了沒有就是沒生效。5. 進階用ASAN自定義分配器定位共享內存踩踏ASAN默認只攔截標準malloc/free和棧/全局變量對自定義分配器比如共享內存池無能為力。在8155p上很多內存問題出在自定義的共享內存分配器上。一個進階做法是給自定義分配器加ASAN的poison/unpoison接口。ASAN提供了__asan_poison_memory_region和__asan_unpoison_memory_region可以在分配時把內存標記為可訪問釋放時標記為不可訪問。這樣越界寫或釋放后寫就會觸發(fā)ASAN報錯。具體實現(xiàn)在你的共享內存分配器里alloc時調用__asan_unpoison_memory_region(ptr, size)free時調用__asan_poison_memory_region(ptr, size)。編譯時需要鏈接ASAN運行時并且確保這些接口在Android9的ASAN運行時里存在。我實測過libclang_rt.asan-aarch64-android.so確實導出了這兩個符號。但要注意poison的粒度是8字節(jié)所以size要按8字節(jié)對齊否則會有誤報。另一個技巧是用ASAN的start_deactivated模式。在進程啟動時先不激活ASAN等關鍵初始化完成后再通過__asan_init激活。這樣可以避免ASAN在init階段和系統(tǒng)庫的沖突。Android9上可以通過ASAN_OPTIONSstart_deactivated1開啟然后在代碼里調用__asan_init()。這個模式對調試啟動階段的內存問題特別有用因為默認ASAN在init階段就會攔截所有分配導致啟動失敗。驗證ASAN是否真正生效可以寫一個故意越界的小程序// asan_check.cpp 驗證ASAN是否生效 #include cstring int main() { char *buf new char[10]; memset(buf, 0, 20); // 故意越界寫 delete[] buf; return 0; }編譯時加-fsanitizeaddress -fno-omit-frame-pointer -g推設備運行。如果ASAN生效會立刻報heap-buffer-overflow并給出堆棧。如果沒有報錯說明插樁或運行時加載有問題回到第2章檢查編譯參數(shù)和庫路徑。最后說一個我自己的習慣每次開ASAN之前先把模塊的strip關掉、-g加上、運行時庫路徑確認一遍這三件事做完再編譯。否則大概率是白抓一輪日志里全是問號后悔藥都沒得吃。ASAN在8155p的QNXAndroid9雙系統(tǒng)上不是一鍵開關而是一套需要按模塊、按場景調整的調試鏈路。把編譯、部署、符號化、跨系統(tǒng)邊界這幾步走通它就能把最玄學的內存問題變成一行明確的代碼位置。希望幫到你。本文還有配套的精品資源點擊獲取