記一次dlopen使用問題導致Framework重啟，tombstones、pmap與反彙編分析（上）

Kryo發表於2024-04-05

關鍵詞：Android Framework 動態庫動態連結 Binder

1、事件起因

Android Studio一次更新後發現install App，裝置就重啟了，跑了一遍開機動畫但不是從開機第一屏開始重啟，tombstones內容檢視發現是surfaceflinger掛在libbinder.so，那install app做了什麼這個不得而知，理論上有問題應該掛的是PackageManagerService。先不管Android Studio的事情，雖然掛在Binder的庫裡，還是首先懷疑問題出在surfaceflinger的Binder使用邏輯。

2、原因分析

`(以下分析使用RockPi4B還原現場)`

tombstone檔案如下

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'rockchip/rk3399_ROCKPI4B_Android11/rk3399_ROCKPI4B_Android11:11/RQ3A.210705.001/eng.kryo.20240128.131540:userdebug/release-keys'
Revision: '0'
ABI: 'arm64'
Timestamp: 2024-01-28 23:42:32+0800
pid: 11263, tid: 11289, name: Binder:11263_2  >>> /system/bin/surfaceflinger <<<
uid: 1000
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x791c0e6cd0
    x0  b4000079ce312fd8  x1  000000005f444d50  x2  000000791d20c9c0  x3  000000791d20c940
    x4  0000000000000010  x5  0000000000000018  x6  b400007a7e312e50  x7  b4000079ce312fd8
    x8  000000791c0e6c50  x9  0000000010000000  x10 0000000000000001  x11 0000000000000002
    x12 0000000000000000  x13 0000007baff5e020  x14 0001096dce96e5c4  x15 0000000029aaaaf0
    x16 0000007bafd6c420  x17 0000007bafd29e30  x18 000000791c592000  x19 000000791d20c940
    x20 0000000000000010  x21 000000791d20c9c0  x22 b4000079ce312fd8  x23 000000005f444d50
    x24 000000791d20d000  x25 0000000000000000  x26 ffffffff000003e8  x27 b400007a7e313014
    x28 0000000000000000  x29 000000791d20c8d0
    lr  0000007bafd167bc  sp  000000791d20c8c0  pc  0000007bafd1685c  pst 0000000080000000

backtrace:
      #00 pc 000000000004985c  /system/lib64/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+228) (BuildId: d5e42e998e9031430bee87f595521231)
      #01 pc 00000000000524a8  /system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+1032) (BuildId: d5e42e998e9031430bee87f595521231)
      #02 pc 0000000000051fec  /system/lib64/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+156) (BuildId: d5e42e998e9031430bee87f595521231)
      #03 pc 000000000005282c  /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+60) (BuildId: d5e42e998e9031430bee87f595521231)
      #04 pc 0000000000078e10  /system/lib64/libbinder.so (android::PoolThread::threadLoop()+24) (BuildId: d5e42e998e9031430bee87f595521231)
      #05 pc 000000000001567c  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+260) (BuildId: c081ab14bd4aef44c9c459d77d8c9b48)
      #06 pc 0000000000014f14  /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+412) (BuildId: c081ab14bd4aef44c9c459d77d8c9b48)
      #07 pc 00000000000b0c08  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: 0a481e8df134382e9d3effff2fce8b74)
      #08 pc 00000000000505d0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 0a481e8df134382e9d3effff2fce8b74)

使用addr2line工具檢視程式碼奔潰處原始碼，aosp編譯時會在out目錄下生成symbols目錄，會額外儲存一份帶符號的so檔案方便回溯問題，把崩潰處的地址4985c傳入

aarch64-linux-android-addr2line -e out/target/product/rk3399_ROCKPI4B_Android11/symbols/system/lib64/libbinder.so 4985c

#frameworks/native/libs/binder/Binder.cpp:188

定位到Binder.cpp 188行處的原始碼：

status_t BBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    data.setDataPosition(0);

    status_t err = NO_ERROR;
    switch (code) {
        case PING_TRANSACTION:
            err = pingBinder();
            break;
        case EXTENSION_TRANSACTION:
            err = reply->writeStrongBinder(getExtension());
            break;
        case DEBUG_PID_TRANSACTION:
            err = reply->writeInt32(getDebugPid());
            break;
        default:
            err = onTransact(code, data, reply, flags); // 188行處
            break;
    }
    //... ...
}

還是目前很難看出崩潰原因，tombstone給出的是SEGV_MAPERR錯誤，推測與訪存有關，再結合objdump -S 檢視libbinder.so的反彙編：

   ... ...

   49840:	1400001a 	b	498a8 <_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j@@Base+0x130>
   49844:	f94002c8 	ldr	x8, [x22]
   49848:	aa1603e0 	mov	x0, x22
   4984c:	2a1703e1 	mov	w1, w23
   49850:	aa1503e2 	mov	x2, x21
   49854:	aa1303e3 	mov	x3, x19
   49858:	2a1403e4 	mov	w4, w20
   4985c:	f9404108 	ldr	x8, [x8,#128]
   49860:	d63f0100 	blr	x8
   ... ...

可以看到4985c處的彙編指令是透過x8暫存器偏移+128位元組進行訪存(暫存器相對定址) x8內容0x791c0e6c50加128正好是出錯記憶體地址0x791c0e6cd0，取得的記憶體結果再存回x8

x8reg

tombstone也會把程序的pmap資訊列印，由於地址空間佈局隨機化（ASLR）機制，可能每次執行結果的地址都不一樣:

memory map (836 entries): (fault address prefixed with --->)
... ...

    00000079'1afe2000-00000079'1bc05fff ---         0    c24000
    00000079'1bc06000-00000079'1bc07fff rw-         0      2000
    00000079'1bc08000-00000079'1bfe1fff ---         0    3da000
    00000079'1bfe2000-00000079'1bfe2fff ---         0      1000
    00000079'1bfe3000-00000079'1c0defff rw-         0     fc000  [anon:stack_and_tls:11290]
    00000079'1c0df000-00000079'1c0dffff ---         0      1000
--->Fault address falls at 00000079'1c0e6cd0 between mapped regions
    00000079'1c113000-00000079'1c591fff ---         0    47f000
    00000079'1c592000-00000079'1c593fff rw-         0      2000
    00000079'1c594000-00000079'1d112fff ---         0    b7f000
    00000079'1d113000-00000079'1d113fff ---         0      1000
... ...

出現錯誤的地址是個空洞，也就是出現空指標，透過對比彙編程式碼和C++程式碼可以得知x0_x3(w0w3)正好是傳遞了4個引數，ldr x8, [x8,#128]準備賦值給x8暫存器onTransact函式型別的函式指標，然後blr x8跳轉到x8執行子程式，說明沒有找到onTransact這個函式地址。

以上分析也不好判斷是前面這個x8暫存器本身出了問題，在執行過程中被意外修改，還是訪問這塊記憶體有毛病被修改了，但還是不要懷疑是binder庫本身的問題，binder是系統核心功能，有問題早就掛在其他地方了。好訊息是這個問題是必現的，我們有足夠的試錯機會。

透過重新搜尋surfaceflinger相關程式碼，發現MTK為其定製了一個庫libsurface_ext.so，擴充套件了一些功能，並且實現了一個名為SurfaceExtService的binder服務新增道ServiceManager裡:

extern "C" void createSurfaceExtService() {
    const sp<IServiceManager> sm = defaultServiceManager();
    if (sm == nullptr) {
        LOGE("Can't get ServiceManager");
    } else {
        sp<IBinder> binder = sm->checkService(String16(SERVICE_NAME));
        if (binder != nullptr) {
            LOGW("SurfaceExtService added");
        } else {
            sp<SurfaceExtService> sfext = new SurfaceExtService();
            sm->addService(String16(SERVICE_NAME), sfext, false);
            LOGI("SurfaceExtService add");
        }
    }
}

透過宏註釋編譯程式碼，去掉SurfaceExtService服務，重新編譯push，再次透過Android Studio安裝應用，surfaceflinger不出現奔潰。這下問題能夠縮小到libsurface_ext.so與binder相關功能。

3、解決問題

反覆看了巨久的程式碼，並不能找到問題，後面突發靈感，還原始碼重新編譯執行surfaceflinger，透過cat /proc/[pid]/maps |grep libsurface_ext命令檢視surfaceflinger的記憶體對映，發現libsurface_ext.so並不在記憶體對映中。

搜尋程式碼發現其動態載入so的位置:

SurfaceExtServiceHelper.cpp

//
// Created by kryo on 1/28/24.
//
#include <log/log.h>
#include <dlfcn.h>

void createSurfaceExtServiceProxy() {
    void* soHandle = dlopen("libsurface_ext.so", RTLD_LAZY);
    if (soHandle) {
        void (*createSurfaceExtPtr)();
        createSurfaceExtPtr = (decltype(createSurfaceExtPtr))(dlsym(soHandle, "createSurfaceExtService"));
        if (NULL == createSurfaceExtPtr) {
            dlclose(soHandle);
            soHandle = nullptr;
            ALOGE("createSurfaceExtService not found");
        } else {
            createSurfaceExtPtr();
            dlclose(soHandle); // ?
            ALOGD("createSurfaceExtPtr()");
        }
    } else {
        soHandle = nullptr;
        ALOGE("lib_surface_ext.so not found");
    }
}

程式碼邏輯dlopen載入libsurface_ext.so庫，然後使用dlsym搜尋符號createSurfaceExtService拿到函式指標並呼叫(看起來和Java反射有點類似)，日誌createSurfaceExtPtr()也成功列印。

乍一看沒有問題，但是為啥maps裡面並沒有libsurface_ext.so，仔細一看createSurfaceExtPtr()呼叫後又呼叫了dlclose()，去掉這個呼叫，重新編譯push，問題不再復現，之前繞了一大圈沒找到bug，原來被這塊給坑了。

回溯下之前的onTransact呼叫出錯的問題，x8暫存器訪問的記憶體所在的區間就是libsurface_ext.so載入的記憶體對映，後面dlclose又把so庫解除安裝了，回頭再看tombstone檔案memory map段也沒有這個so

這個庫使用了binder，有重寫BBinder::onTransact方法:

status_t BBinder::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t /*flags*/);

推測進行Binder呼叫時透過vtable(虛表指標偏移128位元組)訪問該庫Binder物件找被重寫的onTransact函式指標，再跳轉到函式去執行，結果獲取函式指標時訪問的不存在，導致程序crash掉!

呼叫dumpsys、service list等可以觸發surfaceflinger的binder呼叫，均能復現該問題，應該也是Android Studio安裝app能復現的原因。

總結

對於程式碼動態新增binder功能的so庫時，我們儘量儲存開啟的so控制代碼，並在所有業務結束後才能透過dlclose()關閉控制代碼，以防止因so庫的引用計數為0時被系統從記憶體中解除安裝，且對於surfaceflinger這種永不退出的程序來說沒有必要呼叫關閉，這個鍋要甩給MTK開發。

Reference

Linux 動態連結過程中的【重定位】底層原理
《程式設計師的自我修養：連結、裝載與庫》

記一次 Mac 意外重啟導致的 Homestead 問題
2019-07-30
Mac
VXFS啟用非同步IO導致的嚴重問題
2014-11-26
非同步
記一次 Kafka 重啟失敗問題排查
2020-03-16
Kafka
一次JVM記憶體問題導致的線上事故
2020-05-14
JVM記憶體
記一次儲存問題導致的rac故障案例
2022-10-09
使用Nginx解決IIS繫結域名導致應用程式重啟的問題
2014-07-04
Nginx
ANALYZE導致的阻塞問題分析
2020-08-17
記一次crontab中date命令錯用導致的問題
2019-11-18
定時重啟tomcat指令碼導致的亂碼問題
2014-12-22
Tomcat指令碼
線上問題排查：記一次 Redis Cluster Pipeline 導致的死鎖問題
2023-12-04
Redis
LightDB/Postgresql 記錄客戶端啟動版本問題導致啟動失敗問題
2022-05-26
SQL客戶端
一次oracle行級鎖導致的問題
2015-04-12
Oracle
Android之點選Home鍵後再次開啟導致APP重啟問題
2018-09-28
AndroidAPP
記php-fpm重啟導致的一個bug
2019-04-26
PHP
一次錯誤使用 go-cache 導致出現的線上問題
2021-04-27
Go
記錄一次因 mysql 欄位取名不規範導致的問題
2021-07-31
MySql
一次因為修改環境變數導致RESIN不能啟動的問題
2007-09-30
變數
滑鼠問題導致筆記本開機點選桌面和工作列無反應
2015-01-23
筆記
利用Windbg分析Magicodes.IE一次錯誤編寫導致記憶體劇增
2021-12-12
記憶體
記一次檔案亂碼導致PHP原始碼被直接輸出問題
2020-08-21
PHP原始碼
記一次 hosts 檔案配置錯誤導致應用卡頓的奇葩問題
2021-06-18
記一次升級Gradle外掛導致相容問題的解決方案
2020-11-10
Gradle
一次oracle 節點重啟問題的定位
2015-03-10
Oracle
記錄一次重啟伺服器 Redis 資料丟失問題
2019-05-24
伺服器Redis
undo表空間出現壞塊導致資料庫重啟問題解決
2016-12-02
資料庫
golang slice使用不慎導致的問題
2018-05-24
Golang
mingw32 exception在sjlj與dwarf差別-反彙編分析
2020-06-16
Exception
反彙編工具objdump的使用簡介
2016-03-27
OBJ
反彙編命令U
2018-03-22
Go坑：time.After可能導致的記憶體洩露問題分析
2023-05-04
Go記憶體洩露
記一次 Laravel日誌許可權許可權問題（定時器導致）
2020-07-14
Laravel定時器
記一次：歸檔檔案系統問題導致資料庫hang處理
2016-02-02
資料庫
MySQL：一次timestamp時區轉換導致的問題
2019-11-04
MySql
記一次資料庫重啟後歸檔急劇增加的問題
2014-06-08
資料庫
IP地址被清空導致例項重啟
2013-07-19
建立index 使用Online導致的問題
2018-02-06
Index
記一次 .NET某工控宇宙射線導致程式崩潰分析
2023-12-25
PLSQL安裝與使用問題彙總
2020-11-18
SQL