庫符號可見性：同名類實現(xiàn)串門的定位與根治)
先講一次讓我印象深刻的排查經(jīng)歷。內(nèi)部某個工具在測試環(huán)境跑了近兩周都好好的突然某天開始頻繁崩潰backtrace里來來回回都是同一段邏輯兩個獨(dú)立模塊各自封裝了一份字符串處理和配置類類名都叫ConfigManager頭文件幾乎相同但內(nèi)部實現(xiàn)是兩份不一樣的。結(jié)果幾乎所有調(diào)用都走進(jìn)了先加載的那個實現(xiàn)讀取配置時偶爾拿到A模塊的路徑校驗時卻走B模塊的邏輯最后內(nèi)存被按不同布局讀寫直接掛掉。一開始我懷疑是內(nèi)存踩踏排查到懷疑人生后來用LD_DEBUG看了一眼符號綁定才確認(rèn)根子正是Linux動態(tài)庫的符號默認(rèn)全局可見同名類實現(xiàn)之間發(fā)生了“串門”。這類問題如果沒抓住“符號可見性”這個點排查起來很容易繞遠(yuǎn)路。這篇文章就把這個問題的原理、定位手段和根治方案完整講一遍適合維護(hù)大型C/C項目的同學(xué)也適合剛接觸Linux動態(tài)庫、被插件系統(tǒng)里莫名其妙行為搞到頭禿的人。1. 為什么Linux下會“只認(rèn)一個實現(xiàn)”1.1 現(xiàn)場還原兩個同名類各寫各的假設(shè)主程序同時加載了libA.so和libB.so兩個動態(tài)庫都定義了ConfigManager這個類頭文件聲明幾乎一致內(nèi)部實現(xiàn)卻是兩套獨(dú)立演進(jìn)出來的東西。庫A里的實現(xiàn)走的是舊配置格式字段是8字節(jié)對齊庫B里的實現(xiàn)用新格式字段多了兩個成員整體結(jié)構(gòu)體變大了一圈。正常情況下每個.so內(nèi)部調(diào)用自己的ConfigManager井水不犯河水。但Linux的動態(tài)鏈接器不這么想。它在進(jìn)程全局維護(hù)一張動態(tài)符號解析表遇到同名符號時往往采取“先到先得”的策略誰先被加載誰的定義就作為全局統(tǒng)一符號。后面庫里的引用會被解析到前面那個庫的實現(xiàn)上。結(jié)果就是libB編譯時按自己頭文件生成的代碼在運(yùn)行時卻調(diào)用了libA的對象布局和函數(shù)體而libA的對象實際又被libB的代碼按新偏移寫字段。這種ABI不一致一旦發(fā)生表現(xiàn)就是離奇的崩潰、間歇性的數(shù)據(jù)錯亂以及“明明代碼邏輯沒問題卻總在某些環(huán)境下掛”。1.2 源頭在ELF動態(tài)符號表默認(rèn)全部可見要理解這個問題得先回到ELF的機(jī)制。GCC和Clang在編譯動態(tài)庫時默認(rèn)會把所有非static的全局函數(shù)和全局變量都放進(jìn)動態(tài)符號表.dynsym。也就是說只要一個函數(shù)不是寫在文件內(nèi)部的static函數(shù)它就會被子進(jìn)程看到并且可以被其他模塊接管或覆蓋這是Linux與Windows非常大的一個差異。Windows上寫DLL時需要顯式用__declspec(dllexport)導(dǎo)出不寫就不導(dǎo)出默認(rèn)是隱藏的。Linux剛好反過來默認(rèn)全導(dǎo)出只有主動隱藏才不導(dǎo)出。這種設(shè)計在早期 Unix 生態(tài)里有一定的歷史原因允許不同模塊自由共享符號實現(xiàn)類似全局插樁的效果。但代價就是當(dāng)多個模塊各自攜帶同名類實現(xiàn)時會發(fā)生符號介入進(jìn)程里最終只保留一個全局有效的定義。正因為Linux和Windows的默認(rèn)行為完全相反很多跨平臺經(jīng)驗比較豐富的團(tuán)隊在遷移到Linux時反而更容易踩坑在Windows上從來沒有這類問題因為沒主動導(dǎo)出就不會被外面看到到Linux一看動態(tài)符號表里躺著一堆內(nèi)部實現(xiàn)符號沖突是必然的。1.3 類實現(xiàn)錯亂的底層鏈路具體到C場景問題鏈路通常是這樣的每個.so里都有自己的類實現(xiàn)包括成員函數(shù)、虛函數(shù)表vtable和typeinfo符號這些符號都被放進(jìn)了動態(tài)符號表也就是全局可見范圍內(nèi)。主程序加載庫時動態(tài)鏈接器在全局范圍內(nèi)做符號解析。遇到多個相同符號名就按一定順序選一個作為最終綁定目標(biāo)。庫內(nèi)部代碼里對該類方法的調(diào)用發(fā)現(xiàn)全局已經(jīng)有了綁定目標(biāo)就不再綁定自己內(nèi)部那份而是跳到選中的那個實現(xiàn)。因為調(diào)用方編譯時用的是自己的頭文件布局與被調(diào)用的實現(xiàn)版本不一致ABI就崩了。這里面還有一個容易被忽略的細(xì)節(jié)vtable符號和typeinfo符號也是全局符號同樣會被介入。結(jié)果就是dynamic_cast、異常處理、甚至簡單的虛函數(shù)調(diào)用都可能走錯門比普通函數(shù)沖突更隱蔽。2. 先實錘三個命令把“串門”釘死2.1 第一步用nm和readelf看動態(tài)符號表要確認(rèn)是不是符號沖突先看每個.so都導(dǎo)出了什么。最直接的就是用nm只看動態(tài)符號nm -D libA.so | cfilt | grep -i ConfigManager nm -D libB.so | cfilt | grep -i ConfigManager大寫T表示全局可見的text段代碼符號D是已初始化數(shù)據(jù)B是bss段R是只讀數(shù)據(jù)。只要兩個庫都導(dǎo)出了同名符號就能看到重復(fù)的類名出現(xiàn)。如果覺得nm輸出太簡單可以用readelf看更完整的符號表信息readelf -Ws libA.so | grep ConfigManagerreadelf -Ws輸出的內(nèi)容會包含符號所在的段、大小、綁定屬性能更清楚看到哪些是GLOBAL、哪些是LOCAL。如果兩個庫里都出現(xiàn)GLOBAL DEFAULT的同名符號那就要警惕了。這里還有個更高效的組合命令可以一次性找出兩個動態(tài)庫動態(tài)符號的重復(fù)交集comm -12 \ (nm -D --defined-only libA.so | awk {print $3} | sort -u) \ (nm -D --defined-only libB.so | awk {print $3} | sort -u)輸出里出現(xiàn)的每一個符號名都是潛在的沖突源。這個命令我強(qiáng)烈建議放到腳本里作為每個版本發(fā)布前的常規(guī)檢查。2.2 第二步用LD_DEBUG讓鏈接器自己承認(rèn)查看符號表只能說明“有這個可能”要實錘“到底綁到了誰”最好的辦法是讓動態(tài)鏈接器打印綁定過程LD_DEBUGbindings ./demo_app 21 | grep -i ConfigManager輸出里會出現(xiàn)類似這樣的信息binding file libB.so [0x00...] to libA.so [0x00...]: ConfigManager::getConfig() normal symbol注意看binding file這一行的方向libB.so里某個符號綁定到了libA.so。這一條信息基本就是鐵證直接說明了“串門”發(fā)生的位置。還可以配合files模式看加載順序LD_DEBUGfiles ./demo_app 21 | grep so確認(rèn)到底誰先被加載以及先到先得的順序關(guān)系。2.3 第三步崩潰棧交叉驗證如果現(xiàn)場已經(jīng)有core dump或gdb棧同樣可以做交叉驗證。用addr2line把崩潰地址換算成源碼位置addr2line -f -C -e libB.so 0x0000xxxx正常情況下棧幀應(yīng)該落在libB自己的源碼里。如果地址換算出來指向libA的源碼或者gdb里info symbol顯示符號屬于另一個庫那問題就實錘了。我在實際排查中還發(fā)現(xiàn)一個規(guī)律這類崩潰的棧幀符號名通常會“看起來特別正?！薄１热珙惷麑?、方法名對、行號也有但行為完全不對。如果遇到這種“?？粗鴽]啥問題卻崩潰”的詭異現(xiàn)場先別急著懷疑編譯器優(yōu)化或者內(nèi)存踩踏先花兩分鐘查一下符號綁定往往能省掉幾天時間。3. “錯亂”的三種典型形態(tài)3.1 形態(tài)一虛函數(shù)表混亂同名類各自帶有虛函數(shù)時vtable符號也是全局可見的。兩個庫的vtable都進(jìn)了全局符號表最終保留一份可能是A的也可能是B的。運(yùn)行時通過基類指針調(diào)虛函數(shù)實際跳轉(zhuǎn)到的可能是另一個版本的函數(shù)體。這種場景最迷惑人的地方在于代碼調(diào)用關(guān)系本身沒變但實際執(zhí)行的邏輯是錯的版本而且還不一定崩潰可能只是行為偏差。比如A版本里對輸入做了二次校驗B版本沒做。用戶數(shù)據(jù)從B模塊入口進(jìn)來經(jīng)過另一個庫的虛表間接調(diào)用時可能部分走了A的校驗邏輯部分走了B的邏輯最終的數(shù)據(jù)處理結(jié)果處在一個“兩頭都不靠”的狀態(tài)。3.2 形態(tài)二對象布局不一致導(dǎo)致臟寫這是最危險的一種。假設(shè)A版本的Record結(jié)構(gòu)是12字節(jié)B版本因為加了字段變成20字節(jié)。B模塊的函數(shù)按新版本20字節(jié)的偏移寫第16字節(jié)處的字段但這個對象實際是A模塊按12字節(jié)分配出來的對象后面的4字節(jié)屬于別的數(shù)據(jù)。這種臟寫不會馬上崩潰可能過很久才在完全不相干的地方爆出來。我之前遇到的一個典型案例就是配置結(jié)構(gòu)體在庫A按舊版本分配庫B按新版本寫入結(jié)果每次運(yùn)行到特定分支時堆上的相鄰對象被改寫表現(xiàn)為偶發(fā)的“配置讀取結(jié)果被神秘篡改”。想要快速排查這類問題可以把兩個版本的類各自做一個sizeof輸出動態(tài)打印出來對比。如果發(fā)現(xiàn)同一個類名在不同庫里的sizeof不一致就要立刻檢查符號綁定方向。3.3 形態(tài)三靜態(tài)狀態(tài)與單例漂移類的靜態(tài)成員變量、內(nèi)部static局部變量同樣存在多份副本的情況。兩個庫各有一份靜態(tài)狀態(tài)但全局符號解析會決定進(jìn)程實際使用哪一份。最典型的癥狀是日志開關(guān)改了一個庫的靜態(tài)變量另一個庫卻完全不理會或者計數(shù)器本應(yīng)在A模塊里自增結(jié)果讀到的是B模塊那份初始值。還有inline函數(shù)里的靜態(tài)局部變量在C17以前的多庫場景里很容易出現(xiàn)副本分裂。如果這個inline函數(shù)所在的符號被全局可見地導(dǎo)出了多個庫綁定到不同副本時狀態(tài)就徹底分裂了。這類問題編碼階段幾乎無法避免必須靠符號可見性策略做系統(tǒng)性防護(hù)。4. 根治方案符號隱藏、版本腳本、架構(gòu)收斂4.1 最基礎(chǔ)的一步編譯期統(tǒng)一隱藏符號我推薦的第一道防線就是在編譯動態(tài)庫時統(tǒng)一加上-fvisibilityhidden參數(shù)g -fvisibilityhidden -shared -o libB.so b.cpp這個參數(shù)告訴編譯器默認(rèn)情況下所有符號都設(shè)為隱藏只有顯式標(biāo)記了visibility(default)的符號才能進(jìn)入動態(tài)符號表。配合的常見做法是在公共頭文件里定義一個導(dǎo)出宏#if defined(_WIN32) #define API_EXPORT __declspec(dllexport) #else #define API_EXPORT __attribute__((visibility(default))) #endif class API_EXPORT ConfigManager { public: ConfigManager(); std::string getConfig(const std::string key); };這樣類的公共接口被顯式導(dǎo)出類內(nèi)部的輔助函數(shù)、私有方法、模板實例化細(xì)節(jié)默認(rèn)全部隱藏動態(tài)符號表里只剩下一張面很干凈的導(dǎo)出面。我特別強(qiáng)調(diào)一點這個改動需要覆蓋倉庫里所有模塊不能只改出問題的那個。一個庫隱藏了另一個沒隱藏沖突照樣存在。最好把編譯參數(shù)寫進(jìn)公共構(gòu)建預(yù)設(shè)文件讓所有模塊默認(rèn)繼承。也可以加上-Werrorvismismatch在編譯階段就攔截聲明和定義可見性不一致的問題。4.2 更嚴(yán)格的做法用版本腳本做最終閘門-fvisibilityhidden已經(jīng)足夠解決大部分沖突但它還是會讓所有“顯式標(biāo)記了default”的符號進(jìn)入動態(tài)符號表。如果想把導(dǎo)出面收斂到極致可以用鏈接器版本腳本來把關(guān)先寫一個exports.map{ global: api_*; ConfigManager; _ZN7network*; local: *; };然后鏈接時加上g -shared -fPIC -Wl,--version-scriptexports.map -o libB.so b.cpp版本腳本的效果比編譯屬性更徹底它會明確告訴鏈接器除了global段列出的符號名其他一律不導(dǎo)出相當(dāng)于給動態(tài)庫的對外接口畫了一條紅線。這里要特別提醒C的使用者global段里如果要寫類名或命名空間需要用nm -D --defined-only看一下mangled后的符號名再決定寫哪一層通配。比如命名空間network下的類可能需要寫成_ZN7network*的形式而不是直接寫network。用版本腳本的另一個好處是可以做符號版本化symbol versioning。同一個函數(shù)在不同版本里可以定義不同的導(dǎo)出名這屬于更大工程里接口兼容性的玩法但即便暫時用不上版本化單純用local: *;一條規(guī)則做“默認(rèn)關(guān)閉”已經(jīng)足夠值回票價。4.3 插件系統(tǒng)的隔離策略插件場景尤其容易踩雷主程序用dlopen加載兩個插件每個插件各自靜態(tài)鏈接了一份公共庫。如果加載插件時用了RTLD_GLOBAL插件里的全局符號會被合并進(jìn)全局符號表后加載的插件很容易就綁到前面插件的實現(xiàn)上。哪怕改成RTLD_LOCAL也只解決了一部分問題因為插件內(nèi)部如果引用同名符號動態(tài)鏈接器依然可能跨插件解析。我現(xiàn)在的建議是三層配合主程序加載插件時統(tǒng)一使用RTLD_LOCAL不把插件的符號泄漏到全局。插件自身也開啟-fvisibilityhidden插件對外只暴露約定好的幾個入口函數(shù)內(nèi)部符號全部隱藏。如果多個插件都需要同一個公共庫不要在各自插件里靜態(tài)鏈接一份而是單獨(dú)編譯成一個公共依賴.so讓所有插件都鏈接同一個文件。這套組合拳打下來插件之間基本就隔離開了。公共依賴的動態(tài)庫只認(rèn)一個版本不會再出現(xiàn)多份副本爭奪符號的情況。4.4 架構(gòu)層的長期收斂符號隱藏和版本腳本解決的是“符號怎么導(dǎo)出”的問題。但如果架構(gòu)上允許每個模塊各自內(nèi)置一份公共代碼那么沖突源會不斷出現(xiàn)。比較理想的收斂方式是把公共代碼拆到一個獨(dú)立的公共依賴庫所有模塊統(tǒng)一依賴這個庫而不是在各自源碼樹里拷貝一份實現(xiàn)。這里的“公共代碼”不單指自己寫的工具類也包括可能被不同模塊以不同版本靜態(tài)鏈接的第三方庫。如果現(xiàn)狀做不到立刻拆分至少要在編譯參數(shù)上保證所有共用符號面一致的庫使用同一個版本并且所有共享庫都默認(rèn)隱藏符號。C的namespace其實也能起到一定的隔離效果但它的作用只是改變符號的mangled名稱ELF層面還是有同名的可能所以不要把namespace當(dāng)成唯一的防線。5. 實際踩坑記錄與細(xì)節(jié)補(bǔ)充5.1 開啟隱藏后客戶端鏈接不到符號開啟-fvisibilityhidden之后最常見的報錯是鏈接階段出現(xiàn)“undefined reference to xxx”。這個原因通常是對外API的聲明和定義里漏掉了導(dǎo)入側(cè)或者導(dǎo)出側(cè)的標(biāo)記。比如頭文件里類聲明加了API_EXPORT但類內(nèi)某一個成員函數(shù)在實現(xiàn)時又單獨(dú)聲明了一次那個單獨(dú)的成員沒帶visibility(default)標(biāo)記導(dǎo)出時就把它隱藏了。解決辦法也很直白在公共導(dǎo)出宏上統(tǒng)一處理各個平臺到宏里做適配不要在單個函數(shù)上零散加attribute。同時可以打開-v選項或者用nm -D --defined-only確認(rèn)一下編譯后的so到底導(dǎo)出了哪些符號與實際需要導(dǎo)出的接口做對比很快就能找出漏網(wǎng)之魚。5.2 版本腳本的local: *;導(dǎo)致后續(xù)擴(kuò)展失敗版本腳本使用local: *;后新加一個API但忘記更新腳本鏈接器會靜默地不導(dǎo)出它調(diào)用方在運(yùn)行時或鏈接時找不到這個符號。這類問題因為不會報編譯錯誤很容易漏檢。我的習(xí)慣是在構(gòu)建腳本里加一步符號清單校驗每次構(gòu)建后用nm -D --defined-only生成當(dāng)前導(dǎo)出符號列表和版本腳本里聲明的api_*或類名做比對。一旦發(fā)現(xiàn)實際導(dǎo)出的符號有新增但沒有出現(xiàn)在允許名單里就觸發(fā)告警。這支腳本的成本很低但能有效避免“上線后才發(fā)現(xiàn)新接口沒導(dǎo)出”的尷尬局面。5.3 團(tuán)隊分支編譯參數(shù)不一致問題只在部分機(jī)器出現(xiàn)還遇到過更隱蔽的情況同一個庫在A機(jī)器上編譯后運(yùn)行正常在B機(jī)器上就出現(xiàn)符號沖突。排查到最后發(fā)現(xiàn)兩邊機(jī)器用的構(gòu)建參數(shù)不一樣一個開了-fvisibilityhidden另一個沒開。這種“機(jī)器相關(guān)”的現(xiàn)象很容易讓人誤判為環(huán)境問題實際上是編譯產(chǎn)物本身就不一致。比較好的做法是把可見性參數(shù)固化到項目的CMake預(yù)設(shè)或公共編譯配置里禁止各成員在自己的目錄里臨時改編譯選項。同時配套一個腳本掃描倉庫里所有動態(tài)庫的導(dǎo)出符號表凡是有大量非API符號泄漏的直接標(biāo)紅。5.4 動態(tài)加載RTLD_GLOBAL讓沖突擴(kuò)大如果主程序用dlopen加載插件時習(xí)慣性地傳了RTLD_GLOBAL那么插件里的符號就會全部合并到全局符號表。兩個插件都靜態(tài)鏈接了同一個第三方庫的不同版本時第三方庫的內(nèi)部符號也會互相覆蓋。這種場景下即使插件內(nèi)部用了隱藏符號第三方庫如果是默認(rèn)可見編譯的沖突依然會存在。所以我在前面的插件方案里強(qiáng)調(diào)公共依賴一定要單獨(dú)編譯成.so并統(tǒng)一版本別讓插件各自攜帶一份靜態(tài)庫副本。這屬于架構(gòu)層面的取舍短期看要多維護(hù)一個庫長期看能避免非常多符號糾纏的“鬼故事”。6. 問題速查與自查清單6.1 快速判斷表典型癥狀常被誤判的方向確認(rèn)手段處理建議同名類成員函數(shù)行為錯亂內(nèi)存踩踏、編譯器BugLD_DEBUGbindings查看綁定目標(biāo)同名庫統(tǒng)一版本隱藏符號結(jié)構(gòu)體字段被寫入詭異值堆越界、邏輯Bug打印兩個庫中sizeof同名類對比修復(fù)布局版本銜接符號隱藏虛函數(shù)調(diào)用進(jìn)入非預(yù)期實現(xiàn)虛表損壞、驅(qū)動問題gdb info symbol查看符號歸屬vtable符號導(dǎo)出面收斂配置變更對某個模塊不生效緩存問題、配置中心Bug檢查靜態(tài)變量符號是否漂移拆公共依賴統(tǒng)一單例來源插件各自帶一份公共庫后崩潰插件接口不兼容對比插件動態(tài)符號交集公共庫獨(dú)立成.soRTLD_LOCAL6.2 符號自查清單發(fā)布前建議做這樣一輪檢查用nm -D --defined-only確認(rèn)動態(tài)庫導(dǎo)出的符號只有預(yù)期API。用comm比較所有相關(guān)動態(tài)庫的動態(tài)符號交集排查重復(fù)定義。確認(rèn)構(gòu)建參數(shù)里-fvisibilityhidden已經(jīng)全局生效。檢查版本腳本允許名單與實際導(dǎo)出名單是否一致。插件場景下確認(rèn)沒有用RTLD_GLOBAL加載插件插件自身符號已隱藏。確認(rèn)公共第三方庫只以統(tǒng)一版本被所有模塊依賴。6.3 常用工具一行版最后整理一批我平時常敲的命令方便直接復(fù)用# 查看動態(tài)庫實際導(dǎo)出的符號 nm -D --defined-only libX.so | cfilt # 查看符號詳細(xì)信息 readelf -Ws libX.so | grep 符號名 # 對比兩個庫的重復(fù)導(dǎo)出符號 comm -12 \ (nm -D --defined-only libA.so | awk {print $3} | sort -u) \ (nm -D --defined-only libB.so | awk {print $3} | sort -u) # 讓動態(tài)鏈接器打印符號綁定過程 LD_DEBUGbindings ./demo_app 21 | grep 類名 # 將崩潰地址轉(zhuǎn)換為源碼位置 addr2line -f -C -e libX.so 0x4006a0我現(xiàn)在的習(xí)慣是給每個庫的構(gòu)建流程都會掛一個“導(dǎo)出面審計”的收尾步驟構(gòu)建完自動跑一遍導(dǎo)出符號清單只要清單里有白名單之外的符號就立刻告警。這個做法比等人崩潰之后再回頭排查要省太多事了。符號可見性說白了就是動態(tài)庫的接口契約平時多花幾分鐘守住契約運(yùn)行時就能少經(jīng)歷幾次“類實現(xiàn)錯亂”的午夜驚魂。 Linux動態(tài)庫符號可見性：同名類實現(xiàn)串門的定位與根治
先講一次讓我印象深刻的排查經(jīng)歷。內(nèi)部某個工具在測試環(huán)境跑了近兩周都好好的突然某天開始頻繁崩潰backtrace里來來回回都是同一段邏輯兩個獨(dú)立模塊各自封裝了一份字符串處理和配置類類名都叫ConfigManager頭文件幾乎相同但內(nèi)部實現(xiàn)是兩份不一樣的。結(jié)果幾乎所有調(diào)用都走進(jìn)了先加載的那個實現(xiàn)讀取配置時偶爾拿到A模塊的路徑校驗時卻走B模塊的邏輯最后內(nèi)存被按不同布局讀寫直接掛掉。一開始我懷疑是內(nèi)存踩踏排查到懷疑人生后來用LD_DEBUG看了一眼符號綁定才確認(rèn)根子正是Linux動態(tài)庫的符號默認(rèn)全局可見同名類實現(xiàn)之間發(fā)生了“串門”。這類問題如果沒抓住“符號可見性”這個點排查起來很容易繞遠(yuǎn)路。這篇文章就把這個問題的原理、定位手段和根治方案完整講一遍適合維護(hù)大型C/C項目的同學(xué)也適合剛接觸Linux動態(tài)庫、被插件系統(tǒng)里莫名其妙行為搞到頭禿的人。1. 為什么Linux下會“只認(rèn)一個實現(xiàn)”1.1 現(xiàn)場還原兩個同名類各寫各的假設(shè)主程序同時加載了libA.so和libB.so兩個動態(tài)庫都定義了ConfigManager這個類頭文件聲明幾乎一致內(nèi)部實現(xiàn)卻是兩套獨(dú)立演進(jìn)出來的東西。庫A里的實現(xiàn)走的是舊配置格式字段是8字節(jié)對齊庫B里的實現(xiàn)用新格式字段多了兩個成員整體結(jié)構(gòu)體變大了一圈。正常情況下每個.so內(nèi)部調(diào)用自己的ConfigManager井水不犯河水。但Linux的動態(tài)鏈接器不這么想。它在進(jìn)程全局維護(hù)一張動態(tài)符號解析表遇到同名符號時往往采取“先到先得”的策略誰先被加載誰的定義就作為全局統(tǒng)一符號。后面庫里的引用會被解析到前面那個庫的實現(xiàn)上。結(jié)果就是libB編譯時按自己頭文件生成的代碼在運(yùn)行時卻調(diào)用了libA的對象布局和函數(shù)體而libA的對象實際又被libB的代碼按新偏移寫字段。這種ABI不一致一旦發(fā)生表現(xiàn)就是離奇的崩潰、間歇性的數(shù)據(jù)錯亂以及“明明代碼邏輯沒問題卻總在某些環(huán)境下掛”。1.2 源頭在ELF動態(tài)符號表默認(rèn)全部可見要理解這個問題得先回到ELF的機(jī)制。GCC和Clang在編譯動態(tài)庫時默認(rèn)會把所有非static的全局函數(shù)和全局變量都放進(jìn)動態(tài)符號表.dynsym。也就是說只要一個函數(shù)不是寫在文件內(nèi)部的static函數(shù)它就會被子進(jìn)程看到并且可以被其他模塊接管或覆蓋這是Linux與Windows非常大的一個差異。Windows上寫DLL時需要顯式用__declspec(dllexport)導(dǎo)出不寫就不導(dǎo)出默認(rèn)是隱藏的。Linux剛好反過來默認(rèn)全導(dǎo)出只有主動隱藏才不導(dǎo)出。這種設(shè)計在早期 Unix 生態(tài)里有一定的歷史原因允許不同模塊自由共享符號實現(xiàn)類似全局插樁的效果。但代價就是當(dāng)多個模塊各自攜帶同名類實現(xiàn)時會發(fā)生符號介入進(jìn)程里最終只保留一個全局有效的定義。正因為Linux和Windows的默認(rèn)行為完全相反很多跨平臺經(jīng)驗比較豐富的團(tuán)隊在遷移到Linux時反而更容易踩坑在Windows上從來沒有這類問題因為沒主動導(dǎo)出就不會被外面看到到Linux一看動態(tài)符號表里躺著一堆內(nèi)部實現(xiàn)符號沖突是必然的。1.3 類實現(xiàn)錯亂的底層鏈路具體到C場景問題鏈路通常是這樣的每個.so里都有自己的類實現(xiàn)包括成員函數(shù)、虛函數(shù)表vtable和typeinfo符號這些符號都被放進(jìn)了動態(tài)符號表也就是全局可見范圍內(nèi)。主程序加載庫時動態(tài)鏈接器在全局范圍內(nèi)做符號解析。遇到多個相同符號名就按一定順序選一個作為最終綁定目標(biāo)。庫內(nèi)部代碼里對該類方法的調(diào)用發(fā)現(xiàn)全局已經(jīng)有了綁定目標(biāo)就不再綁定自己內(nèi)部那份而是跳到選中的那個實現(xiàn)。因為調(diào)用方編譯時用的是自己的頭文件布局與被調(diào)用的實現(xiàn)版本不一致ABI就崩了。這里面還有一個容易被忽略的細(xì)節(jié)vtable符號和typeinfo符號也是全局符號同樣會被介入。結(jié)果就是dynamic_cast、異常處理、甚至簡單的虛函數(shù)調(diào)用都可能走錯門比普通函數(shù)沖突更隱蔽。2. 先實錘三個命令把“串門”釘死2.1 第一步用nm和readelf看動態(tài)符號表要確認(rèn)是不是符號沖突先看每個.so都導(dǎo)出了什么。最直接的就是用nm只看動態(tài)符號nm -D libA.so | cfilt | grep -i ConfigManager nm -D libB.so | cfilt | grep -i ConfigManager大寫T表示全局可見的text段代碼符號D是已初始化數(shù)據(jù)B是bss段R是只讀數(shù)據(jù)。只要兩個庫都導(dǎo)出了同名符號就能看到重復(fù)的類名出現(xiàn)。如果覺得nm輸出太簡單可以用readelf看更完整的符號表信息readelf -Ws libA.so | grep ConfigManagerreadelf -Ws輸出的內(nèi)容會包含符號所在的段、大小、綁定屬性能更清楚看到哪些是GLOBAL、哪些是LOCAL。如果兩個庫里都出現(xiàn)GLOBAL DEFAULT的同名符號那就要警惕了。這里還有個更高效的組合命令可以一次性找出兩個動態(tài)庫動態(tài)符號的重復(fù)交集comm -12 \ (nm -D --defined-only libA.so | awk {print $3} | sort -u) \ (nm -D --defined-only libB.so | awk {print $3} | sort -u)輸出里出現(xiàn)的每一個符號名都是潛在的沖突源。這個命令我強(qiáng)烈建議放到腳本里作為每個版本發(fā)布前的常規(guī)檢查。2.2 第二步用LD_DEBUG讓鏈接器自己承認(rèn)查看符號表只能說明“有這個可能”要實錘“到底綁到了誰”最好的辦法是讓動態(tài)鏈接器打印綁定過程LD_DEBUGbindings ./demo_app 21 | grep -i ConfigManager輸出里會出現(xiàn)類似這樣的信息binding file libB.so [0x00...] to libA.so [0x00...]: ConfigManager::getConfig() normal symbol注意看binding file這一行的方向libB.so里某個符號綁定到了libA.so。這一條信息基本就是鐵證直接說明了“串門”發(fā)生的位置。還可以配合files模式看加載順序LD_DEBUGfiles ./demo_app 21 | grep so確認(rèn)到底誰先被加載以及先到先得的順序關(guān)系。2.3 第三步崩潰棧交叉驗證如果現(xiàn)場已經(jīng)有core dump或gdb棧同樣可以做交叉驗證。用addr2line把崩潰地址換算成源碼位置addr2line -f -C -e libB.so 0x0000xxxx正常情況下棧幀應(yīng)該落在libB自己的源碼里。如果地址換算出來指向libA的源碼或者gdb里info symbol顯示符號屬于另一個庫那問題就實錘了。我在實際排查中還發(fā)現(xiàn)一個規(guī)律這類崩潰的棧幀符號名通常會“看起來特別正?！薄１热珙惷麑?、方法名對、行號也有但行為完全不對。如果遇到這種“?？粗鴽]啥問題卻崩潰”的詭異現(xiàn)場先別急著懷疑編譯器優(yōu)化或者內(nèi)存踩踏先花兩分鐘查一下符號綁定往往能省掉幾天時間。3. “錯亂”的三種典型形態(tài)3.1 形態(tài)一虛函數(shù)表混亂同名類各自帶有虛函數(shù)時vtable符號也是全局可見的。兩個庫的vtable都進(jìn)了全局符號表最終保留一份可能是A的也可能是B的。運(yùn)行時通過基類指針調(diào)虛函數(shù)實際跳轉(zhuǎn)到的可能是另一個版本的函數(shù)體。這種場景最迷惑人的地方在于代碼調(diào)用關(guān)系本身沒變但實際執(zhí)行的邏輯是錯的版本而且還不一定崩潰可能只是行為偏差。比如A版本里對輸入做了二次校驗B版本沒做。用戶數(shù)據(jù)從B模塊入口進(jìn)來經(jīng)過另一個庫的虛表間接調(diào)用時可能部分走了A的校驗邏輯部分走了B的邏輯最終的數(shù)據(jù)處理結(jié)果處在一個“兩頭都不靠”的狀態(tài)。3.2 形態(tài)二對象布局不一致導(dǎo)致臟寫這是最危險的一種。假設(shè)A版本的Record結(jié)構(gòu)是12字節(jié)B版本因為加了字段變成20字節(jié)。B模塊的函數(shù)按新版本20字節(jié)的偏移寫第16字節(jié)處的字段但這個對象實際是A模塊按12字節(jié)分配出來的對象后面的4字節(jié)屬于別的數(shù)據(jù)。這種臟寫不會馬上崩潰可能過很久才在完全不相干的地方爆出來。我之前遇到的一個典型案例就是配置結(jié)構(gòu)體在庫A按舊版本分配庫B按新版本寫入結(jié)果每次運(yùn)行到特定分支時堆上的相鄰對象被改寫表現(xiàn)為偶發(fā)的“配置讀取結(jié)果被神秘篡改”。想要快速排查這類問題可以把兩個版本的類各自做一個sizeof輸出動態(tài)打印出來對比。如果發(fā)現(xiàn)同一個類名在不同庫里的sizeof不一致就要立刻檢查符號綁定方向。3.3 形態(tài)三靜態(tài)狀態(tài)與單例漂移類的靜態(tài)成員變量、內(nèi)部static局部變量同樣存在多份副本的情況。兩個庫各有一份靜態(tài)狀態(tài)但全局符號解析會決定進(jìn)程實際使用哪一份。最典型的癥狀是日志開關(guān)改了一個庫的靜態(tài)變量另一個庫卻完全不理會或者計數(shù)器本應(yīng)在A模塊里自增結(jié)果讀到的是B模塊那份初始值。還有inline函數(shù)里的靜態(tài)局部變量在C17以前的多庫場景里很容易出現(xiàn)副本分裂。如果這個inline函數(shù)所在的符號被全局可見地導(dǎo)出了多個庫綁定到不同副本時狀態(tài)就徹底分裂了。這類問題編碼階段幾乎無法避免必須靠符號可見性策略做系統(tǒng)性防護(hù)。4. 根治方案符號隱藏、版本腳本、架構(gòu)收斂4.1 最基礎(chǔ)的一步編譯期統(tǒng)一隱藏符號我推薦的第一道防線就是在編譯動態(tài)庫時統(tǒng)一加上-fvisibilityhidden參數(shù)g -fvisibilityhidden -shared -o libB.so b.cpp這個參數(shù)告訴編譯器默認(rèn)情況下所有符號都設(shè)為隱藏只有顯式標(biāo)記了visibility(default)的符號才能進(jìn)入動態(tài)符號表。配合的常見做法是在公共頭文件里定義一個導(dǎo)出宏#if defined(_WIN32) #define API_EXPORT __declspec(dllexport) #else #define API_EXPORT __attribute__((visibility(default))) #endif class API_EXPORT ConfigManager { public: ConfigManager(); std::string getConfig(const std::string key); };這樣類的公共接口被顯式導(dǎo)出類內(nèi)部的輔助函數(shù)、私有方法、模板實例化細(xì)節(jié)默認(rèn)全部隱藏動態(tài)符號表里只剩下一張面很干凈的導(dǎo)出面。我特別強(qiáng)調(diào)一點這個改動需要覆蓋倉庫里所有模塊不能只改出問題的那個。一個庫隱藏了另一個沒隱藏沖突照樣存在。最好把編譯參數(shù)寫進(jìn)公共構(gòu)建預(yù)設(shè)文件讓所有模塊默認(rèn)繼承。也可以加上-Werrorvismismatch在編譯階段就攔截聲明和定義可見性不一致的問題。4.2 更嚴(yán)格的做法用版本腳本做最終閘門-fvisibilityhidden已經(jīng)足夠解決大部分沖突但它還是會讓所有“顯式標(biāo)記了default”的符號進(jìn)入動態(tài)符號表。如果想把導(dǎo)出面收斂到極致可以用鏈接器版本腳本來把關(guān)先寫一個exports.map{ global: api_*; ConfigManager; _ZN7network*; local: *; };然后鏈接時加上g -shared -fPIC -Wl,--version-scriptexports.map -o libB.so b.cpp版本腳本的效果比編譯屬性更徹底它會明確告訴鏈接器除了global段列出的符號名其他一律不導(dǎo)出相當(dāng)于給動態(tài)庫的對外接口畫了一條紅線。這里要特別提醒C的使用者global段里如果要寫類名或命名空間需要用nm -D --defined-only看一下mangled后的符號名再決定寫哪一層通配。比如命名空間network下的類可能需要寫成_ZN7network*的形式而不是直接寫network。用版本腳本的另一個好處是可以做符號版本化symbol versioning。同一個函數(shù)在不同版本里可以定義不同的導(dǎo)出名這屬于更大工程里接口兼容性的玩法但即便暫時用不上版本化單純用local: *;一條規(guī)則做“默認(rèn)關(guān)閉”已經(jīng)足夠值回票價。4.3 插件系統(tǒng)的隔離策略插件場景尤其容易踩雷主程序用dlopen加載兩個插件每個插件各自靜態(tài)鏈接了一份公共庫。如果加載插件時用了RTLD_GLOBAL插件里的全局符號會被合并進(jìn)全局符號表后加載的插件很容易就綁到前面插件的實現(xiàn)上。哪怕改成RTLD_LOCAL也只解決了一部分問題因為插件內(nèi)部如果引用同名符號動態(tài)鏈接器依然可能跨插件解析。我現(xiàn)在的建議是三層配合主程序加載插件時統(tǒng)一使用RTLD_LOCAL不把插件的符號泄漏到全局。插件自身也開啟-fvisibilityhidden插件對外只暴露約定好的幾個入口函數(shù)內(nèi)部符號全部隱藏。如果多個插件都需要同一個公共庫不要在各自插件里靜態(tài)鏈接一份而是單獨(dú)編譯成一個公共依賴.so讓所有插件都鏈接同一個文件。這套組合拳打下來插件之間基本就隔離開了。公共依賴的動態(tài)庫只認(rèn)一個版本不會再出現(xiàn)多份副本爭奪符號的情況。4.4 架構(gòu)層的長期收斂符號隱藏和版本腳本解決的是“符號怎么導(dǎo)出”的問題。但如果架構(gòu)上允許每個模塊各自內(nèi)置一份公共代碼那么沖突源會不斷出現(xiàn)。比較理想的收斂方式是把公共代碼拆到一個獨(dú)立的公共依賴庫所有模塊統(tǒng)一依賴這個庫而不是在各自源碼樹里拷貝一份實現(xiàn)。這里的“公共代碼”不單指自己寫的工具類也包括可能被不同模塊以不同版本靜態(tài)鏈接的第三方庫。如果現(xiàn)狀做不到立刻拆分至少要在編譯參數(shù)上保證所有共用符號面一致的庫使用同一個版本并且所有共享庫都默認(rèn)隱藏符號。C的namespace其實也能起到一定的隔離效果但它的作用只是改變符號的mangled名稱ELF層面還是有同名的可能所以不要把namespace當(dāng)成唯一的防線。5. 實際踩坑記錄與細(xì)節(jié)補(bǔ)充5.1 開啟隱藏后客戶端鏈接不到符號開啟-fvisibilityhidden之后最常見的報錯是鏈接階段出現(xiàn)“undefined reference to xxx”。這個原因通常是對外API的聲明和定義里漏掉了導(dǎo)入側(cè)或者導(dǎo)出側(cè)的標(biāo)記。比如頭文件里類聲明加了API_EXPORT但類內(nèi)某一個成員函數(shù)在實現(xiàn)時又單獨(dú)聲明了一次那個單獨(dú)的成員沒帶visibility(default)標(biāo)記導(dǎo)出時就把它隱藏了。解決辦法也很直白在公共導(dǎo)出宏上統(tǒng)一處理各個平臺到宏里做適配不要在單個函數(shù)上零散加attribute。同時可以打開-v選項或者用nm -D --defined-only確認(rèn)一下編譯后的so到底導(dǎo)出了哪些符號與實際需要導(dǎo)出的接口做對比很快就能找出漏網(wǎng)之魚。5.2 版本腳本的local: *;導(dǎo)致后續(xù)擴(kuò)展失敗版本腳本使用local: *;后新加一個API但忘記更新腳本鏈接器會靜默地不導(dǎo)出它調(diào)用方在運(yùn)行時或鏈接時找不到這個符號。這類問題因為不會報編譯錯誤很容易漏檢。我的習(xí)慣是在構(gòu)建腳本里加一步符號清單校驗每次構(gòu)建后用nm -D --defined-only生成當(dāng)前導(dǎo)出符號列表和版本腳本里聲明的api_*或類名做比對。一旦發(fā)現(xiàn)實際導(dǎo)出的符號有新增但沒有出現(xiàn)在允許名單里就觸發(fā)告警。這支腳本的成本很低但能有效避免“上線后才發(fā)現(xiàn)新接口沒導(dǎo)出”的尷尬局面。5.3 團(tuán)隊分支編譯參數(shù)不一致問題只在部分機(jī)器出現(xiàn)還遇到過更隱蔽的情況同一個庫在A機(jī)器上編譯后運(yùn)行正常在B機(jī)器上就出現(xiàn)符號沖突。排查到最后發(fā)現(xiàn)兩邊機(jī)器用的構(gòu)建參數(shù)不一樣一個開了-fvisibilityhidden另一個沒開。這種“機(jī)器相關(guān)”的現(xiàn)象很容易讓人誤判為環(huán)境問題實際上是編譯產(chǎn)物本身就不一致。比較好的做法是把可見性參數(shù)固化到項目的CMake預(yù)設(shè)或公共編譯配置里禁止各成員在自己的目錄里臨時改編譯選項。同時配套一個腳本掃描倉庫里所有動態(tài)庫的導(dǎo)出符號表凡是有大量非API符號泄漏的直接標(biāo)紅。5.4 動態(tài)加載RTLD_GLOBAL讓沖突擴(kuò)大如果主程序用dlopen加載插件時習(xí)慣性地傳了RTLD_GLOBAL那么插件里的符號就會全部合并到全局符號表。兩個插件都靜態(tài)鏈接了同一個第三方庫的不同版本時第三方庫的內(nèi)部符號也會互相覆蓋。這種場景下即使插件內(nèi)部用了隱藏符號第三方庫如果是默認(rèn)可見編譯的沖突依然會存在。所以我在前面的插件方案里強(qiáng)調(diào)公共依賴一定要單獨(dú)編譯成.so并統(tǒng)一版本別讓插件各自攜帶一份靜態(tài)庫副本。這屬于架構(gòu)層面的取舍短期看要多維護(hù)一個庫長期看能避免非常多符號糾纏的“鬼故事”。6. 問題速查與自查清單6.1 快速判斷表典型癥狀常被誤判的方向確認(rèn)手段處理建議同名類成員函數(shù)行為錯亂內(nèi)存踩踏、編譯器BugLD_DEBUGbindings查看綁定目標(biāo)同名庫統(tǒng)一版本隱藏符號結(jié)構(gòu)體字段被寫入詭異值堆越界、邏輯Bug打印兩個庫中sizeof同名類對比修復(fù)布局版本銜接符號隱藏虛函數(shù)調(diào)用進(jìn)入非預(yù)期實現(xiàn)虛表損壞、驅(qū)動問題gdb info symbol查看符號歸屬vtable符號導(dǎo)出面收斂配置變更對某個模塊不生效緩存問題、配置中心Bug檢查靜態(tài)變量符號是否漂移拆公共依賴統(tǒng)一單例來源插件各自帶一份公共庫后崩潰插件接口不兼容對比插件動態(tài)符號交集公共庫獨(dú)立成.soRTLD_LOCAL6.2 符號自查清單發(fā)布前建議做這樣一輪檢查用nm -D --defined-only確認(rèn)動態(tài)庫導(dǎo)出的符號只有預(yù)期API。用comm比較所有相關(guān)動態(tài)庫的動態(tài)符號交集排查重復(fù)定義。確認(rèn)構(gòu)建參數(shù)里-fvisibilityhidden已經(jīng)全局生效。檢查版本腳本允許名單與實際導(dǎo)出名單是否一致。插件場景下確認(rèn)沒有用RTLD_GLOBAL加載插件插件自身符號已隱藏。確認(rèn)公共第三方庫只以統(tǒng)一版本被所有模塊依賴。6.3 常用工具一行版最后整理一批我平時常敲的命令方便直接復(fù)用# 查看動態(tài)庫實際導(dǎo)出的符號 nm -D --defined-only libX.so | cfilt # 查看符號詳細(xì)信息 readelf -Ws libX.so | grep 符號名 # 對比兩個庫的重復(fù)導(dǎo)出符號 comm -12 \ (nm -D --defined-only libA.so | awk {print $3} | sort -u) \ (nm -D --defined-only libB.so | awk {print $3} | sort -u) # 讓動態(tài)鏈接器打印符號綁定過程 LD_DEBUGbindings ./demo_app 21 | grep 類名 # 將崩潰地址轉(zhuǎn)換為源碼位置 addr2line -f -C -e libX.so 0x4006a0我現(xiàn)在的習(xí)慣是給每個庫的構(gòu)建流程都會掛一個“導(dǎo)出面審計”的收尾步驟構(gòu)建完自動跑一遍導(dǎo)出符號清單只要清單里有白名單之外的符號就立刻告警。這個做法比等人崩潰之后再回頭排查要省太多事了。符號可見性說白了就是動態(tài)庫的接口契約平時多花幾分鐘守住契約運(yùn)行時就能少經(jīng)歷幾次“類實現(xiàn)錯亂”的午夜驚魂。