程序跑著跑著突然崩了日志里只有一句“Segmentation fault”連是哪個(gè)函數(shù)、哪一行出的問題都不給這種場景但凡在Linux下寫過C/C的人應(yīng)該都遇到過。尤其是線上服務(wù)core文件不一定開、gdb不一定裝、復(fù)現(xiàn)還不一定穩(wěn)最后只能靠加打印一行行猜。其實(shí)Linux本身提供了一套相當(dāng)成熟的運(yùn)行時(shí)調(diào)用?；厮輽C(jī)制能在程序活著的時(shí)候把當(dāng)前函數(shù)調(diào)用鏈、返回地址、甚至對應(yīng)的源文件和行號直接打出來不需要掛調(diào)試器也不需要等崩潰。這篇就圍繞“程序運(yùn)行時(shí)打印調(diào)用棧信息”這件事把backtrace、符號解析、行號還原、編譯選項(xiàng)配合、以及實(shí)際落地時(shí)那些文檔里不會(huì)寫的坑完整拆一遍。適合已經(jīng)能寫C程序、但被線上問題折磨過、想把自診斷能力做進(jìn)代碼里的開發(fā)者參考也適合剛接觸Linux調(diào)試體系、想搞明白“?；厮莸降自趺垂ぷ鳌钡呐笥选?. 先搞清楚運(yùn)行時(shí)?；厮莸降自诮鉀Q什么問題很多人第一反應(yīng)是“崩潰了用gdb看不就行了”。這話在本地開發(fā)階段沒錯(cuò)但放到真實(shí)場景里就站不住了。我先把運(yùn)行時(shí)打印調(diào)用棧和傳統(tǒng)調(diào)試手段的差異擺出來你就明白為什么值得單獨(dú)做一套機(jī)制。1.1 調(diào)試器依賴與線上環(huán)境的現(xiàn)實(shí)矛盾gdb這類工具的工作前提是你能在出問題的機(jī)器上啟動(dòng)它、能拿到可執(zhí)行文件、能拿到符號信息、最好還能復(fù)現(xiàn)。這四條在線上環(huán)境里經(jīng)常同時(shí)不成立。生產(chǎn)機(jī)器為了精簡和安全通常不會(huì)裝完整的調(diào)試工具鏈可執(zhí)行文件可能被strip過core dump策略出于磁盤考慮往往是關(guān)閉的偶發(fā)問題更是難以穩(wěn)定復(fù)現(xiàn)。這時(shí)候你手里剩下的唯一線索就是程序自己愿意吐出來的日志。運(yùn)行時(shí)?；厮莸暮诵膬r(jià)值就在這它把“事后調(diào)試”變成了“事中自證”。程序在關(guān)鍵路徑上主動(dòng)調(diào)用一次回溯把當(dāng)前調(diào)用鏈寫進(jìn)日志問題發(fā)生時(shí)你直接翻日志就能看到調(diào)用路徑不需要任何外部工具介入。這相當(dāng)于給程序內(nèi)置了一個(gè)輕量級的現(xiàn)場記錄儀。1.2 調(diào)用棧在內(nèi)存里長什么樣要理解怎么打印得先知道棧上有什么。x86-64架構(gòu)下函數(shù)調(diào)用靠的是棧幀stack frame鏈。每次調(diào)用被調(diào)函數(shù)會(huì)在棧上保存調(diào)用者的棧基址rbp形成一個(gè)鏈表結(jié)構(gòu)當(dāng)前rbp指向的棧單元里存著上一層rbp再上一層又存著更上一層的rbp。順著這條鏈一路往上走就能把每一層的返回地址return address收集起來。返回地址是關(guān)鍵它指向“調(diào)用指令的下一條指令”也就是函數(shù)執(zhí)行完要回到的位置。把這個(gè)地址映射回符號表就能知道它屬于哪個(gè)函數(shù)再結(jié)合調(diào)試信息就能還原出源文件和行號。所以整個(gè)回溯過程本質(zhì)上是三步沿棧幀鏈?zhǔn)占祷氐刂?→ 地址轉(zhuǎn)符號 → 符號轉(zhuǎn)行號。后面所有工具和接口都是圍繞這三步做封裝。注意編譯器優(yōu)化會(huì)破壞棧幀鏈。開啟幀指針省略-fomit-frame-pointer后rbp被挪作通用寄存器鏈就斷了。這是后面要專門處理的一個(gè)大坑。1.3 三種主流實(shí)現(xiàn)路徑的取舍Linux下做運(yùn)行時(shí)回溯常見的有三條路各有適用邊界方案依賴優(yōu)點(diǎn)局限glibc backtraceexecinfo.h零額外依賴接口極簡依賴幀指針優(yōu)化后可能不全libunwind獨(dú)立庫支持DWARF展開優(yōu)化代碼也能回溯需引入第三方庫接口略重編譯器內(nèi)建__builtin_return_address無依賴只能逐層取層數(shù)需手動(dòng)控制大多數(shù)項(xiàng)目我會(huì)優(yōu)先用glibc的backtrace因?yàn)樗銐蚝唵?、夠用配合正確的編譯選項(xiàng)能覆蓋九成場景。只有在高度優(yōu)化、幀指針被徹底省略且無法改編譯選項(xiàng)的情況下才考慮libunwind。這個(gè)取舍邏輯后面會(huì)展開講。2. glibc backtrace接口的用法與符號解析鏈路選定方案后真正動(dòng)手時(shí)你會(huì)發(fā)現(xiàn)backtrace本身只有兩個(gè)函數(shù)但“打印出人能看懂的信息”這件事難點(diǎn)全在符號解析上。這一章把接口用法和解析鏈路講透。2.1 backtrace與backtrace_symbols的分工glibc提供的核心接口就兩個(gè)#include execinfo.h int backtrace(void **buffer, int size); char **backtrace_symbols(void *const *buffer, int size);backtrace負(fù)責(zé)填充地址數(shù)組返回實(shí)際抓到的層數(shù)backtrace_symbols負(fù)責(zé)把地址數(shù)組翻譯成字符串?dāng)?shù)組。這里有個(gè)容易忽略的點(diǎn)backtrace_symbols內(nèi)部會(huì)malloc一塊內(nèi)存來存放所有字符串用完必須手動(dòng)free否則每次調(diào)用都漏一塊。而backtrace_symbols_fd是它的兄弟接口直接把結(jié)果寫到文件描述符不經(jīng)過malloc在信號處理函數(shù)里更安全。一個(gè)最小可用的封裝大概長這樣#include execinfo.h #include stdio.h #include stdlib.h void print_stack(void) { void *buffer[64]; int nptrs backtrace(buffer, 64); char **strings backtrace_symbols(buffer, nptrs); if (strings NULL) { perror(backtrace_symbols); return; } for (int i 0; i nptrs; i) { printf(%s\n, strings[i]); } free(strings); }跑起來輸出大概是這樣一行行的./demo(0x11a9) [0x55f...] ./demo(0x1256) [0x55f...] /lib/x86_64-linux-gnu/libc.so.6(0x29d90) [0x7f...]看到問題了嗎只有偏移地址沒有函數(shù)名沒有文件名行號。這就是很多人第一次用backtrace后覺得“沒啥用”的原因——接口給了但符號沒解析出來。2.2 為什么默認(rèn)輸出只有偏移地址backtrace_symbols的輸出質(zhì)量取決于可執(zhí)行文件里有沒有動(dòng)態(tài)符號表。默認(rèn)編譯出來的程序符號表里只有動(dòng)態(tài)鏈接需要的少量符號函數(shù)名大多不在其中所以只能顯示“模塊名偏移”。要讓它顯示函數(shù)名編譯時(shí)必須加-rdynamic等價(jià)于鏈接時(shí)加--export-dynamic把所有符號導(dǎo)出到動(dòng)態(tài)符號表。gcc -g -rdynamic demo.c -o demo加上之后輸出會(huì)變成./demo(print_stack0x1a) [0x55f...] ./demo(main0x2c) [0x55f...]函數(shù)名有了但文件名和行號還是沒有。因?yàn)閎acktrace_symbols只查符號表不查調(diào)試信息。行號還原是另一套機(jī)制得靠addr2line或者dladdr配合調(diào)試段來完成。2.3 用addr2line把地址還原成文件行號拿到偏移地址后最直接的行號還原方式是調(diào)用addr2line。但注意backtrace_symbols給的是“模塊內(nèi)偏移”而addr2line需要的是“虛擬地址減去模塊加載基址”后的偏移兩者在非PIE程序里恰好一致在PIE程序里需要做減法。這就是為什么很多人直接拿輸出地址喂給addr2line結(jié)果得到??:0。正確做法是先用dladdr拿到模塊基址算出真實(shí)偏移再交給addr2line。或者更省事——直接在程序里用backtrace_symbols拿到帶偏移的字符串解析出偏移值再拼成addr2line -e 模塊名 偏移去執(zhí)行。不過運(yùn)行時(shí)fork子進(jìn)程執(zhí)行外部命令有性能和安全性顧慮更優(yōu)雅的方案是鏈接libbfd或libdw在進(jìn)程內(nèi)解析但那就重了。我的經(jīng)驗(yàn)是開發(fā)調(diào)試階段用addr2line腳本后處理日志完全夠用線上環(huán)境如果確實(shí)需要行號優(yōu)先在編譯時(shí)保留調(diào)試信息并用libdw做進(jìn)程內(nèi)解析或者干脆接受“函數(shù)名偏移”這個(gè)粒度。因?yàn)榻^大多數(shù)線上問題定位到函數(shù)名就已經(jīng)能圈定范圍了行號屬于錦上添花。2.4 一個(gè)可直接復(fù)用的解析腳本把日志里的地址批量還原成行號我常用這么一段shell#!/bin/bash # 用法: ./resolve.sh 可執(zhí)行文件 日志文件 BIN$1 LOG$2 grep -oP 0x[0-9a-f] $LOG | while read addr; do echo -n $addr - addr2line -e $BIN -f -C $addr done-f輸出函數(shù)名-C做C符號demangle。這個(gè)腳本在排查偶發(fā)崩潰時(shí)救過我很多次——日志里存著原始地址事后拿對應(yīng)版本的可執(zhí)行文件一跑調(diào)用鏈清清楚楚。前提是可執(zhí)行文件版本必須和產(chǎn)生日志的版本完全一致否則地址對不上這是硬約束。3. 編譯選項(xiàng)決定回溯質(zhì)量-g、-rdynamic與幀指針的三角關(guān)系上一章反復(fù)提到編譯選項(xiàng)這一章專門把它們之間的關(guān)系理清楚。因?yàn)檫\(yùn)行時(shí)回溯能不能用、好不好用八成取決于編譯時(shí)怎么配。3.1 -g與調(diào)試信息的取舍-g生成DWARF調(diào)試信息是行號還原的前提。沒有它addr2line只能給出函數(shù)名還得有符號表給不出文件和行號。但-g會(huì)讓可執(zhí)行文件顯著變大線上發(fā)布時(shí)很多人會(huì)strip掉。這里有個(gè)折中技巧用-g編譯但發(fā)布時(shí)用objcopy --only-keep-debug把調(diào)試信息單獨(dú)抽成一個(gè).debug文件存起來主程序strip掉調(diào)試段但保留符號表。這樣線上程序體積可控出問題時(shí)拿.debug文件配合addr2line照樣能還原行號。gcc -g -rdynamic demo.c -o demo objcopy --only-keep-debug demo demo.debug strip --strip-debug demo # 事后解析 addr2line -e demo.debug -f -C 0x11a9這套流程我在多個(gè)項(xiàng)目里用過兼顧了體積和可診斷性值得固化進(jìn)構(gòu)建腳本。3.2 -rdynamic到底改了什么前面說過-rdynamic讓函數(shù)名出現(xiàn)在輸出里但它的實(shí)際作用是把所有符號加入動(dòng)態(tài)符號表.dynsym而不只是鏈接需要的那些。副作用是可執(zhí)行文件的動(dòng)態(tài)符號表變大加載時(shí)符號解析稍慢一點(diǎn)點(diǎn)但通?？梢院雎?。需要提醒的是-rdynamic只影響“能不能看到函數(shù)名”不影響行號。有人加了-rdynamic發(fā)現(xiàn)還是沒有行號就以為選項(xiàng)沒用其實(shí)是把兩件事混為一談了。函數(shù)名靠符號表行號靠調(diào)試信息兩條獨(dú)立的鏈路。3.3 幀指針省略最隱蔽的回溯殺手這是最容易踩的坑?，F(xiàn)代編譯器在-O2及以上默認(rèn)開啟-fomit-frame-pointer把rbp省出來當(dāng)通用寄存器用。結(jié)果就是棧幀鏈斷裂backtrace只能抓到當(dāng)前函數(shù)和少數(shù)幾層再往上就亂了或者提前終止。解決辦法有兩個(gè)編譯時(shí)顯式加-fno-omit-frame-pointer強(qiáng)制保留幀指針。代價(jià)是少一個(gè)通用寄存器性能有輕微損失通常1%以內(nèi)絕大多數(shù)場景可接受。改用libunwind它基于DWARF的CFI信息做棧展開不依賴幀指針。代價(jià)是引入依賴、接口更復(fù)雜。我的建議是如果項(xiàng)目能控制編譯選項(xiàng)優(yōu)先-fno-omit-frame-pointer glibc backtrace簡單可靠如果是接手的遺留系統(tǒng)、編譯選項(xiàng)動(dòng)不了再上libunwind。這個(gè)決策順序能省掉大量折騰。3.4 一組推薦的編譯配置綜合下來需要運(yùn)行時(shí)回溯的模塊我一般用這套CFLAGS -g -O2 -fno-omit-frame-pointer -rdynamic-g保行號-O2保性能-fno-omit-frame-pointer保棧幀鏈-rdynamic保函數(shù)名。四個(gè)選項(xiàng)各司其職缺一個(gè)回溯質(zhì)量就掉一檔。如果對體積敏感再疊加前面說的debug文件分離方案。提示-O2配合-fno-omit-frame-pointer時(shí)某些內(nèi)聯(lián)函數(shù)仍然不會(huì)出現(xiàn)在棧里因?yàn)閮?nèi)聯(lián)本質(zhì)上是把函數(shù)體展開沒有獨(dú)立棧幀。看到調(diào)用鏈“缺層”先別懷疑工具想想是不是被內(nèi)聯(lián)了。4. 把回溯嵌進(jìn)真實(shí)代碼信號處理與日志落地的工程細(xì)節(jié)接口會(huì)用了、編譯選項(xiàng)配好了接下來是把它嵌進(jìn)真實(shí)項(xiàng)目。這一步的坑不在API而在“什么時(shí)候調(diào)、在什么上下文調(diào)、結(jié)果往哪寫”。4.1 在信號處理函數(shù)里打印崩潰棧最常見的落地場景是捕獲崩潰信號SIGSEGV、SIGABRT等在信號處理函數(shù)里打印調(diào)用棧。但信號處理函數(shù)有嚴(yán)格的異步信號安全約束只能調(diào)用可重入函數(shù)不能malloc不能用printf。而backtrace_symbols內(nèi)部會(huì)mallocprintf也不是異步信號安全的。所以信號處理里應(yīng)該用backtracebacktrace_symbols_fd的組合直接寫文件描述符#include signal.h #include execinfo.h #include unistd.h #include fcntl.h static void crash_handler(int sig) { void *buffer[64]; int nptrs backtrace(buffer, 64); int fd open(/tmp/crash.log, O_WRONLY | O_CREAT | O_APPEND, 0644); if (fd 0) { backtrace_symbols_fd(buffer, nptrs, fd); close(fd); } signal(sig, SIG_DFL); raise(sig); }注意最后兩行恢復(fù)默認(rèn)處理并重新raise讓程序按正常流程終止該產(chǎn)生core還是產(chǎn)生core而不是被我們的handler吞掉。這個(gè)細(xì)節(jié)很多人漏掉導(dǎo)致崩潰被“吃掉”、進(jìn)程狀態(tài)異常。4.2 主動(dòng)埋點(diǎn)在關(guān)鍵路徑而非只等崩潰信號處理只能抓崩潰但很多問題不崩潰——比如邏輯卡死、返回了錯(cuò)誤結(jié)果、性能突然劣化。這類場景更適合在關(guān)鍵路徑上主動(dòng)埋點(diǎn)條件觸發(fā)時(shí)打印當(dāng)前棧。比如一個(gè)請求處理函數(shù)檢測到耗時(shí)超過閾值就把當(dāng)前調(diào)用棧打出來if (elapsed_ms 500) { log_warn(slow path detected, dumping stack:); print_stack_to_log(); }這種“條件回溯”比無差別打印有用得多日志量可控信噪比高。我在一個(gè)服務(wù)里給慢查詢加了這套很快就定位到某個(gè)鎖競爭導(dǎo)致的偶發(fā)卡頓比翻監(jiān)控指標(biāo)快多了。4.3 日志落地的幾個(gè)實(shí)操約束回溯信息寫日志時(shí)有幾個(gè)細(xì)節(jié)值得注意加時(shí)間戳和線程ID。多線程程序里光有調(diào)用棧不知道是哪個(gè)線程打的等于白打。用syscall(SYS_gettid)拿內(nèi)核線程ID和日志框架的線程標(biāo)識(shí)對齊。限制層數(shù)。64層通常夠用太深既拖慢速度又刷屏。遞歸調(diào)用特別深的場景可以適當(dāng)調(diào)大但要評估開銷。控制頻率。高頻路徑上無條件打印會(huì)拖垮性能務(wù)必加條件或采樣。注意日志切割。崩潰棧往往一次寫一大段如果日志框架有單條長度限制可能被截?cái)嘁崆按_認(rèn)。4.4 多線程環(huán)境下的一個(gè)隱蔽問題backtrace本身是線程安全的但如果你在信號處理里打印而信號可能打斷任意線程就要小心信號處理函數(shù)運(yùn)行在被打斷線程的棧上此時(shí)backtrace抓到的棧是“信號處理函數(shù) 被打斷位置”的混合棧前幾層是信號框架真正的崩潰點(diǎn)要往下找。這個(gè)特性不是bug但解讀日志時(shí)要知道別被前幾層__restore_rt之類的框架函數(shù)迷惑。5. 踩過的坑與排查鏈路實(shí)錄這一章不講新接口專門復(fù)盤幾個(gè)真實(shí)踩過的坑把排查過程完整走一遍因?yàn)檫@些東西文檔里基本不會(huì)寫。5.1 加了-rdynamic還是只有地址一次完整的定位過程現(xiàn)象按文檔加了-rdynamicbacktrace_symbols輸出依然是./demo(0x11a9)沒有函數(shù)名。排查鏈路先確認(rèn)選項(xiàng)真的生效了。用readelf -s demo | grep FUNC看動(dòng)態(tài)符號表里有沒有目標(biāo)函數(shù)。結(jié)果發(fā)現(xiàn)目標(biāo)函數(shù)不在.dynsym里。懷疑是靜態(tài)函數(shù)。檢查代碼果然是static void helper()。靜態(tài)函數(shù)不導(dǎo)出到動(dòng)態(tài)符號表-rdynamic也救不了。驗(yàn)證把static去掉重新編譯函數(shù)名出現(xiàn)了。結(jié)論-rdynamic只導(dǎo)出有外部鏈接屬性的符號static函數(shù)天然不可見。如果確實(shí)需要回溯靜態(tài)函數(shù)只能靠調(diào)試信息addr2line而不是符號表。這個(gè)區(qū)分很關(guān)鍵很多人卡在這里以為是選項(xiàng)沒生效。5.2 回溯只有兩層就斷了幀指針被優(yōu)化掉現(xiàn)象backtrace返回的層數(shù)明顯偏少調(diào)用鏈在中間某處就斷了。排查鏈路用objdump -d demo | grep -A2 func:看函數(shù)序言發(fā)現(xiàn)沒有push %rbp; mov %rsp,%rbp說明幀指針被省略了。確認(rèn)編譯選項(xiàng)果然帶了-O2且沒加-fno-omit-frame-pointer。加上該選項(xiàng)重編層數(shù)恢復(fù)正常。這個(gè)坑的隱蔽之處在于程序功能完全正常只有回溯不全不專門驗(yàn)證根本發(fā)現(xiàn)不了。所以我的習(xí)慣是凡是依賴回溯的模塊構(gòu)建后跑一個(gè)自檢用例斷言回溯層數(shù)達(dá)到預(yù)期把這個(gè)問題擋在發(fā)布前。5.3 addr2line返回??:0的三種原因拿到地址喂給addr2line卻得到??:0原因通常有三類現(xiàn)象原因解決全部??:0可執(zhí)行文件沒帶-g重新用-g編譯或用對應(yīng)debug文件部分??:0地址是PIE偏移未減基址用dladdr算基址后相減特定函數(shù)??:0該地址落在庫函數(shù)內(nèi)換對應(yīng)庫的debug符號文件第三類最容易被忽略調(diào)用棧里混著libc的函數(shù)拿主程序的debug文件去解析libc地址當(dāng)然解不出。要針對每個(gè)模塊用各自的符號文件。5.4 信號處理里用printf導(dǎo)致的二次崩潰現(xiàn)象崩潰時(shí)打印棧結(jié)果程序直接卡死或又崩一次日志沒寫出來。原因信號處理函數(shù)里調(diào)了printf而printf內(nèi)部有鎖和緩沖區(qū)操作不是異步信號安全的。如果信號恰好打斷了printf自身就會(huì)死鎖。修復(fù)改用write或backtrace_symbols_fd直接寫fd全程不碰stdio。這個(gè)坑的教訓(xùn)是信號處理函數(shù)里能用什么、不能用什么必須嚴(yán)格對照異步信號安全函數(shù)列表憑直覺寫遲早出事。6. 性能開銷評估與生產(chǎn)環(huán)境的啟用策略最后聊聊大家最關(guān)心的這玩意兒到底多慢線上能不能常開。6.1 單次回溯的耗時(shí)構(gòu)成一次完整回溯的耗時(shí)主要在三塊抓地址backtrace本身微秒級、符號解析backtrace_symbols涉及內(nèi)存分配和符號查找?guī)资綆装傥⒚搿懭罩救Q于IO。實(shí)測在普通x86機(jī)器上抓64層地址加符號解析單次大約在幾十微秒量級具體隨層數(shù)和符號數(shù)量浮動(dòng)。這個(gè)開銷放在低頻路徑崩潰處理、慢請求告警完全無感放在每秒幾十萬次的高頻路徑上就是災(zāi)難。所以啟用策略的核心是按場景分級而不是一刀切。6.2 分級啟用策略我一般這么分崩潰信號處理無條件啟用反正進(jìn)程要掛了開銷無所謂。錯(cuò)誤返回路徑條件啟用比如連續(xù)失敗N次才打一次避免刷屏。性能告警路徑采樣啟用比如每100次超閾值只打1次兼顧可觀測性和開銷。正常高頻路徑默認(rèn)關(guān)閉需要時(shí)通過配置或信號動(dòng)態(tài)打開。這種分級讓回溯能力“隨時(shí)可用但不常開”是生產(chǎn)環(huán)境的穩(wěn)妥做法。6.3 用信號動(dòng)態(tài)開關(guān)回溯一個(gè)實(shí)用技巧注冊一個(gè)用戶信號比如SIGUSR1收到時(shí)把全局的回溯開關(guān)翻轉(zhuǎn)。線上排查時(shí)給進(jìn)程發(fā)個(gè)信號就能臨時(shí)打開詳細(xì)回溯排查完再發(fā)一次關(guān)掉不用重啟、不用改配置。static volatile sig_atomic_t g_trace_on 0; static void toggle_handler(int sig) { (void)sig; g_trace_on !g_trace_on; }注意開關(guān)變量要用sig_atomic_t保證讀寫原子性。這個(gè)機(jī)制在定位偶發(fā)問題時(shí)特別好用相當(dāng)于給線上進(jìn)程裝了個(gè)可遠(yuǎn)程觸發(fā)的“探針”。6.4 別忘了驗(yàn)證回溯本身是否可靠最后強(qiáng)調(diào)一個(gè)容易被忽視的點(diǎn)回溯機(jī)制自己也可能出問題幀指針被優(yōu)化、符號被strip、地址算錯(cuò)。所以要有自檢手段——在啟動(dòng)時(shí)或測試用例里主動(dòng)打一次已知調(diào)用鏈的棧斷言層數(shù)和函數(shù)名符合預(yù)期。把回溯當(dāng)成一個(gè)需要測試的功能而不是“配了就一定對”的黑盒這個(gè)意識(shí)能幫你避免在真正出事時(shí)才發(fā)現(xiàn)回溯是壞的。我個(gè)人在實(shí)際項(xiàng)目里的體會(huì)是運(yùn)行時(shí)調(diào)用棧這套東西配起來不復(fù)雜難的是把編譯選項(xiàng)、符號解析、信號安全、性能開銷這幾件事同時(shí)照顧到。一開始圖省事只調(diào)backtrace結(jié)果線上真出事時(shí)發(fā)現(xiàn)只有地址沒有函數(shù)名那種感覺比沒有日志還難受。后來把-g -fno-omit-frame-pointer -rdynamic固化成模板、把debug文件分離寫進(jìn)構(gòu)建腳本、把信號處理和條件埋點(diǎn)做成通用組件才算真正把這套能力用起來。如果你現(xiàn)在正準(zhǔn)備給項(xiàng)目加這個(gè)能力建議先從崩潰信號處理這一條鏈路做通跑穩(wěn)了再往主動(dòng)埋點(diǎn)擴(kuò)展步子別邁太大。