試實戰(zhàn)指南：從崩潰定位到多線程排查)
前陣子幫同事排查一個線上崩潰程序跑了大半天才掛掛在哪一行完全看不出來日志里最后一條信息還離崩潰點十萬八千里。折騰了半個下午最后上了GDB兩分鐘定位到一處野指針。從那之后我就一直在想Linux下做C/C開發(fā)的人GDB是早晚要邁過去的一道坎早點掌握它后面能省下無數(shù)加班的夜晚。這篇文章不是想給你羅列一大堆命令手冊而是把我實際用GDB排查問題時最常用、最有效的那套東西整理出來包括編譯期就得做對的準備、崩潰現(xiàn)場的分析思路、斷點和單步的精髓、多線程調(diào)試的注意點以及幾個教程里很少寫的坑。無論你是剛接觸Linux開發(fā)的新手還是寫過一段時間但對GDB只停留在“會用start和next”階段的人看完這篇應該都能直接上手解決實際項目里的問題。1. 為什么Linux下調(diào)試離不開GDB1.1 日志排查的邊界很多人寫程序習慣用printf遇到bug就打日志。日志確實有用尤其適合排查業(yè)務邏輯問題。但有一類問題靠日志很難搞典型的就是段錯誤、棧溢出、非法內(nèi)存訪問。這類崩潰偶爾復現(xiàn)甚至只在壓力測試時出現(xiàn)你根本不知道在哪個函數(shù)、哪一條指令觸發(fā)了它打再多的printf都是盲人摸象。還有數(shù)據(jù)競爭這類問題兩個線程同時改一個變量日志順序看起來完全正常但結果就是不對。這時候你需要的是逐行審視代碼在內(nèi)存里到底干了什么需要看到每一個變量的實際值、每一塊內(nèi)存的實時內(nèi)容而GDB的核心價值就在這里它能讓你把程序“暫?！痹谌我庖粋€你關心的時刻然后你就能看清這個時刻的所有細節(jié)。我個人的習慣是邏輯問題先查日志查不到就用GDB跨過“靠猜加盲目打印”的階段。實際項目里GDB解決頻率最高的問題就三類——崩潰閃退、邏輯結果不正確、多線程跑飛每一類GDB都有成熟的調(diào)試套路。1.2 GDB到底能做什么GDB全名GNU Debugger是Linux平臺上最主流的調(diào)試器。它的能力要從三個層面看控制執(zhí)行斷點、單步、繼續(xù)運行到指定位置、跳過或進入函數(shù)觀察現(xiàn)場打印變量、查看?；厮?、查看內(nèi)存、查看寄存器、查看線程和進程狀態(tài)修改現(xiàn)場運行時修改變量值、強制函數(shù)返回、跳過某段代碼用這個能模擬各種邊界條件我見過有人用GDB十幾年就記住了三個命令break、run、print。這三個確實能解決一部分問題但如果你只知道這三個遇到斷點打不上、變量被優(yōu)化掉、多線程死鎖、core文件解析不了的時候就會卡住。所以后面我會把常用的場景串起來講不只是堆命令。注意不需要把GDB幾百個命令都背下來真正的核心命令不超過二十個熟練使用它們已經(jīng)能覆蓋絕大多數(shù)調(diào)試場景了。2. 準備工作編譯期就要做對的事2.1 -g參數(shù)決定了你調(diào)的是什么GDB調(diào)試時依賴調(diào)試信息來建立“源碼行號 ? 二進制指令 ? 變量地址”之間的對應關系。要讓GDB能告訴你“程序崩在第3個文件第27行”前提是編譯時加了-g參數(shù)gcc -g -o demo demo.c-g會讓編譯器在二進制文件里生成一個調(diào)試信息段包含源碼行號、變量名、函數(shù)名、參數(shù)類型這些元數(shù)據(jù)。沒有這個信息GDB看到的全是十六進制地址和匯編指令雖然也能調(diào)但難度直接上升一個臺階。另外一個容易被忽視的參數(shù)是-g3。它比-g多包含宏定義信息如果你調(diào)試的程序里用到宏想用info macro查看宏的展開結果就得在-g后面加一個3。我的建議是項目調(diào)試版本統(tǒng)一用-g3編譯成本差別不大。還有一點很多人忽略了編譯器優(yōu)化對調(diào)試體驗的影響見下一節(jié)。2.2 優(yōu)化選項與調(diào)試信息的恩怨編譯時常用的優(yōu)化選項有-O0、-O1、-O2。優(yōu)化開得越高編譯器的重排、內(nèi)聯(lián)、寄存器變量優(yōu)化就越激進最終產(chǎn)出的機器碼和你寫的源碼之間差異就越大。我用一個實際踩過的坑說明某個問題在-O0下正常、在-O2下必現(xiàn)于是我在發(fā)布版本上直接跑GDB想定位結果print某個局部變量提示“value optimized out”單步走的時候發(fā)現(xiàn)代碼在odd跳步你明明在源碼第10行執(zhí)行完第11行之后居然跳到了第15行。這不是GDB壞了而是編譯器把中間的計算過程優(yōu)化掉了有些變量只存在于寄存器里甚至直接被常數(shù)替代掉了。所以我的建議很明確排查崩潰類問題時先用-O0編譯一個調(diào)試版本問題在調(diào)試版本能復現(xiàn)就先在調(diào)試版本上定位如果問題只在-O2下復現(xiàn)也不要硬剛優(yōu)化代碼試著添加-fno-omit-frame-pointer保留棧幀指針并且在關鍵函數(shù)上用__attribute__((optimize(O0)))做局部關閉優(yōu)化。記住一個原則先在未優(yōu)化版本上把邏輯調(diào)試清楚再去分析優(yōu)化版本的特殊行為而不是直接在高優(yōu)化級別下硬調(diào)。還有一個參數(shù)值得了解-fno-stack-protector。有些發(fā)行版默認開了棧保護越界時程序會主動abort而不是崩在真正越界的代碼里這有時會誤導排查方向。定位棧溢出時先關掉它往往能看到更原始的崩潰位置。2.3 啟動GDB的幾種姿勢GDB不僅僅是“gdb ./program”這一種玩法實際工作中我常用的有四種場景命令適用情況普通調(diào)試gdb ./demo程序能穩(wěn)定復現(xiàn)問題傳參調(diào)試gdb --args ./demo arg1 arg2程序依賴啟動參數(shù)掛載進程gdb -p 23456程序在跑且不好重啟分析coredumpgdb ./demo core.12345程序崩潰后有core文件掛載進程這個功能特別實用生產(chǎn)環(huán)境出問題不想立刻重啟進程時可以用gdb -p加到進程上抓現(xiàn)場。但注意掛上去之后進程是暫停的別忘了在結尾用detach把它放掉否則進程就一直卡住了。分析core文件是我最推薦的崩潰排查方式后面第3節(jié)再展開聊。2.4 自動化批處理.gdbinit與-batch模式日常調(diào)試總有反復輸入幾條固定命令的場景比如啟動后先設置斷點、然后打印參數(shù)。你可以在當前目錄或用戶目錄寫一個.gdbinit文件GDB啟動時會自動讀取并執(zhí)行里面的命令。下面是我的一個示例set pagination off set print pretty on set print thread-events offset pagination off很關鍵它關閉了GDB的分頁提示否則輸出一多就出現(xiàn)“---Type to continue”卡在那里批處理腳本里直接就沒法跑了。還有一種用法是在腳本里跑非交互式調(diào)試。比如定時任務里程序崩了第二天想快速拿到棧直接用一行命令輸出然后退出gdb -batch -ex run -ex bt --args ./demo-batch表示非交互模式逐條執(zhí)行-ex參數(shù)指定的命令全跑完自動退出。我在寫自動化測試腳本時經(jīng)常用它批量檢查崩潰棧不用人工干預。3. 核心調(diào)試實操從一個崩潰程序說起3.1 程序崩潰后第一件事看?；厮菹瓤匆粋€能穩(wěn)定復現(xiàn)段錯誤的例子后面就用它來演示GDB的核心操作。源碼是這樣的#include stdio.h #include string.h char *safe_strcpy(char *buf, const char *src) { if (src NULL) { strcpy(buf, unknown); } else { strcpy(buf, src); } return buf; } int main() { char buf[32]; strcpy(buf, abcdefg); safe_strcpy(buf, NULL); printf(result: %s\n, buf); return 0; }我故意讓strcpy收到NULL指針編譯運行后直接段錯誤。這種問題用日志幾乎沒法查因為你根本不知道哪個函數(shù)傳進了NULL。用GDB復現(xiàn)的流程是gcc -g -O0 -o demo demo.c gdb ./demo進到GDB后輸入run程序跑起來崩潰Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58這里GDB已經(jīng)告訴你崩在strcpy的匯編實現(xiàn)里。但這還遠遠不夠重要的問題是是誰調(diào)用了strcpy參數(shù)傳進來的src到底是不是NULL此時輸入bt也就是backtrace查看當前線程的函數(shù)調(diào)用棧(gdb) bt #0 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 #2 0x0000000000401245 in main () at demo.c:15這一下就清楚了。?；厮輹谐鰪谋罎r的最內(nèi)層函數(shù)到最外層函數(shù)的完整調(diào)用鏈每一幀還附帶關鍵參數(shù)值。你看第1幀里safe_strcpy的src0x0直接就露出來了NULL指針的元兇馬上鎖定。bt之后一般搭配的是frame命令切到指定棧幀然后查看局部變量(gdb) frame 1 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 9 strcpy(buf, unknown); (gdb) info args buf 0x7fffffffdf50 abcdefg src 0x0記住這個流程化打法崩了之后先看bt拿到整個調(diào)用鏈再切frame到目標幀查看參數(shù)和局部變量。80%的崩潰問題靠這一步就能定位出原因。3.2 斷點的正確打開方式崩潰排查只是GDB的一面另一面是主動出擊程序還沒崩但你知道某個函數(shù)可能有問題想在它被調(diào)用時停下來看看。這時候用break設置斷點。GDB里斷點的核心命令其實就幾種break safe_strcpy # 在函數(shù)入口打斷點 break demo.c:8 # 在源文件第8行打斷點 break demo.c:8 if len 0 # 條件斷點滿足條件才暫停條件斷點非常實用。比如一個循環(huán)跑一萬次第9000次結果不對你不想被斷點打斷9000次直接寫break demo.c:8 if i 9000程序會在i等于9000的時候才停下來。這就是硬件/軟件斷點加上條件判斷的配合。還有一個我經(jīng)常用的命令是tbreak臨時斷點只觸發(fā)一次自動刪除。比如只是想停在一個位置看一眼不想讓斷點殘留用這個就很干凈。查看和刪除斷點info breakpoints # 列出所有斷點及其狀態(tài) delete 1 # 刪除編號為1的斷點 disable 2 # 禁用編號為2的斷點保留位置 enable 2 # 重新啟用實踐中我見過有人把幾十個斷點全堆在代碼里斷點太多會互相干擾每個暫停都會檢查一遍條件嚴重影響運行速度。我的習慣是一次只保留三到五個斷點解決完一批馬上刪掉或禁用。3.3 單步執(zhí)行next、step、until怎么選斷點命中后最重要的是逐行看清程序的執(zhí)行過程。GDB里三個最常見的單步命令長的很像但語義差別很大next執(zhí)行當前行遇到函數(shù)調(diào)用直接跳過也叫“單步跳過”step執(zhí)行當前行如果遇到函數(shù)調(diào)用就進去也叫“單步進入”until在循環(huán)里一直執(zhí)行直到到達指定行號或退出循環(huán)用demo舉例子。我在main函數(shù)第12行strcpy(buf, abcdefg)處打斷點run進去后(gdb) next 13 safe_strcpy(buf, NULL); (gdb) next Program received signal SIGSEGV, Segmentation fault.第一次next執(zhí)行完strcpy第二次next直接步入safe_strcpy的調(diào)用結果就崩了。注意next在遇到函數(shù)調(diào)用時是整體執(zhí)行完再停到下一條語句的所以如果函數(shù)內(nèi)部崩潰next會直接帶著你看到崩潰現(xiàn)場。如果我想看safe_strcpy內(nèi)部是怎么走的要用step(gdb) break demo.c:12 (gdb) run Breakpoint 1, main () at demo.c:12 12 strcpy(buf, abcdefg); (gdb) next 13 safe_strcpy(buf, NULL); (gdb) step safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5 5 if (src NULL) {step把你帶進了safe_strcpy函數(shù)體內(nèi)。之后第6行的strcpy(buf, unknown)如果真的執(zhí)行又會二次步入庫函數(shù)內(nèi)部。如果想跳出當前函數(shù)回到調(diào)用者用finish(gdb) finish Run till exit from #0 safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5finish是“執(zhí)行完當前函數(shù)然后停在返回處”非常常用尤其在盯著一個函數(shù)內(nèi)部執(zhí)行完之后的調(diào)用現(xiàn)場時。until的典型場景是循環(huán)。你想在一個循環(huán)里快速執(zhí)行到某個位置但又不想一行一行next按幾百次直接until demo.c:20就能一口氣跑到第20行。注意使用step進入庫函數(shù)時GDB經(jīng)常會一頭扎進printf、strcpy這類C庫的內(nèi)部實現(xiàn)里面全是匯編對排查業(yè)務邏輯沒啥幫助。遇到這種情況直接finish跳出去或者干脆用next避免進入。3.4 變量、內(nèi)存與寄存器看變量最常用的是print命令后面跟變量名或表達式(gdb) print src $1 (char *) 0x0 (gdb) print buf $2 0x7fffffffdf50 abcdefg (gdb) print/x 12345 $3 0x3039print的格式控制符很重要不同場景要用不同的格式p/x 按十六進制看指針和地址p/d 按十進制看整數(shù)p/c 按字符看字節(jié)p/s 按字符串看內(nèi)容p *ptrcount 看指針指向的連續(xù)count個元素比如看到指針地址是0x7fffffffdf50懷疑它指向的內(nèi)存被寫壞了想看看它前16個字節(jié)的內(nèi)容(gdb) x/16bx 0x7fffffffdf50 0x7fffffffdf50: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x00 0x7fffffffdf58: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x61到0x67是abcdefg的ASCII碼后面的0x00是被strcpy寫入的字符串終止符。x命令的格式是x/長度格式單位大小 地址b是單字節(jié)、w是四字節(jié)、g是八字節(jié)。這個組合能幫你看清任意內(nèi)存區(qū)域的實際內(nèi)容排查越界寫、內(nèi)存覆寫時是神器。查看寄存器用info registers調(diào)試匯編和棧問題時有用(gdb) info registers rip rsp rbp rip 0x7ffff7e2b3c8 rsp 0x7fffffffdf48 rbp 0x7fffffffdf60在實際調(diào)試里打印變量的優(yōu)先級高于看寄存器后者主要用于底層匯編分析、函數(shù)調(diào)用約定排查這類場景。4. 多線程調(diào)試崩潰只是表象4.1 定位死鎖和數(shù)據(jù)競爭多線程程序出問題時經(jīng)常會發(fā)現(xiàn)單獨的某個線程看起來都“正常”但整體結果不對。GDB提供了查看所有線程并切換線程的能力。用一個最簡單的多線程自增程序演示兩個線程同時對共享變量做自增缺少鎖保護最終結果大概率小于2000。編譯時注意加lpthreadgcc -g -O0 -o demo_thread demo_thread.c -lpthreadGDB里看到線程列表(gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7dbc740 (LWP 23456) demo_thread main () at demo_thread.c:23 2 Thread 0x7ffff75bc700 (LWP 23457) demo_thread worker (arg0x0) at demo_thread.c:10帶*號的是當前調(diào)試線程。切換到線程2(gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff75bc700 (LWP 23457))]注意切換線程后GDB會暫停在那個線程當前執(zhí)行的指令上。接下來可以用bt查看這個線程的棧用info locals看它的局部變量。要同時看所有線程的棧用(gdb) thread apply all bt這條命令在定位死鎖時特別管用。死鎖的典型特征是多個線程各自卡在不同的鎖等待上你用thread apply all bt能看到每個線程停在哪個鎖函數(shù)里比如線程A卡在pthread_mutex_lock占有鎖X線程B卡在pthread_mutex_lock占有鎖Y而A在等Y、B在等X死鎖閉環(huán)立刻顯現(xiàn)。確認了數(shù)據(jù)競爭下一步就要靠watch命令監(jiān)視某個變量何時被修改(gdb) watch shared Hardware watchpoint 2: shared (gdb) continue每當shared的值發(fā)生變化GDB就會暫停并且打印先前的值和新的值。連續(xù)watch幾次你就能看到兩個線程交錯修改shared的現(xiàn)場數(shù)據(jù)競爭引發(fā)的丟更新操作就暴露出來了。4.2 如何跟蹤fork出的子進程多進程程序用fork創(chuàng)建子進程很常見GDB默認只跟蹤父進程子進程會脫離調(diào)試。如果你想調(diào)試子進程需要在fork之前設置set follow-fork-mode child set detach-on-fork offset follow-fork-mode child讓GDB在fork后自動跟隨子進程set detach-on-fork off讓父進程繼續(xù)保持被調(diào)試狀態(tài)兩個進程都在GDB控制下可以用info inferiors命令查看和管理多條進程上下文。這里有個經(jīng)驗多進程調(diào)試時建議先搞清問題出在哪個進程再決定跟著誰。不加區(qū)分地同時調(diào)試兩個進程會頻繁被另一個進程的斷點打斷調(diào)試效率反而暴跌。實際項目里我一般先只跟父進程如果確認問題在子進程再切過去。4.3 多線程調(diào)試的個人經(jīng)驗多線程調(diào)試容易踩的坑比單線程多得多分享幾個壓箱底的經(jīng)驗。第一個是線程切換和斷點之間的配合。默認情況下你在主線程設置斷點后運行只有主線程命中斷點會暫停其他線程命中相同斷點也會各自暫停。但有的時候你只想讓指定線程停下來set scheduler-locking on這條命令開啟調(diào)度鎖GDB暫停一個線程后其他線程也跟著暫停不會被單獨放跑。在排查數(shù)據(jù)競爭時這個尤其重要否則你在觀察線程A時線程B卻在后臺瘋狂跑變量內(nèi)容一直在變你根本看不準。第二個是開線程事件開關。GDB默認會在每個線程創(chuàng)建和退出時打印一堆事件信息調(diào)試復雜程序時非常刷屏set print thread-events off第三個是別急著在懷疑的代碼上單步。多線程程序單步執(zhí)行會影響時序很多時候多線程bug一旦進入單步就復現(xiàn)不出來了。我的經(jīng)驗是先用日志和perf工具縮小范圍明確到具體幾行代碼后再把GDB的斷點精準設在那幾行上用continue讓程序高速跑到斷點附近而不是從main開始一步步走。5. 常見問題與排查技巧實錄5.1 常見問題速查表把大家問得最多、我自己也踩過的場景整理成一個表格按圖索驥用起來非常方便現(xiàn)象常見原因排查手段崩在庫函數(shù)里參數(shù)非法多為空指針bt看調(diào)用棧frame切到上層print變量顯示optimized out編譯優(yōu)化把變量優(yōu)化掉了改用-O0編譯或?qū)ｍ楆P閉優(yōu)化斷點打在函數(shù)上不生效斷點處被編譯器內(nèi)聯(lián)掉改成在文件行號打斷點程序一run就退出常因找不到動態(tài)庫或參數(shù)錯誤用info sharedlibrary和set args檢查core文件gdb讀不出來生成core時沒保存可執(zhí)行文件確保core和對應可執(zhí)行文件版本匹配多線程加斷點后程序卡死斷點命中后進入鎖等待用scheduler-locking onbt看鎖狀態(tài)崩潰在-O2下必現(xiàn)-O0正常優(yōu)化改變了執(zhí)行路徑單獨用-fno-omit-frame-pointer復現(xiàn)分析5.2 調(diào)試時我見過最坑的幾個現(xiàn)象先說“變量被優(yōu)化掉”。這個在大型代碼庫里特別常見尤其release版本。你明明在源碼里能看到那個變量print卻告訴你optimized out。我第一次遇到時以為GDB壞了后來才明白是編譯器把變量直接揉進了表達式里根本沒有分配內(nèi)存位置。排查思路是一不要在高優(yōu)化級別下浪費時間先換-O0二不要指望所有變量都非得能print改成在函數(shù)入口用info args看參數(shù)或者特意留一個全局變量記錄關鍵狀態(tài)。再說“斷點打不上去”。有的時候你在函數(shù)名上breakGDB卻提示“No symbol table is loaded”或者斷點設到了一個內(nèi)存地址但永遠不命中。最常見原因是函數(shù)被編譯器內(nèi)聯(lián)了斷點實際對應不到入口。解決辦法很簡單要么在源碼行號上打斷點要么臨時用noinline屬性阻止內(nèi)聯(lián)__attribute__((noinline)) static int helper(int x) { return x * 2; }第三個坑是core文件版本不匹配。GDB要求core文件和產(chǎn)生它的可執(zhí)行文件完全匹配否則bt出來全是“No symbol table info available”這種鬼話。很多人程序崩了只把core拷回來不拷可執(zhí)行文件結果根本看不出什么問題。正確的搬家姿勢是core文件和對應版本的二進制一起打包拿回來。5.3 一些提升效率的小技巧除了大塊的調(diào)試技能還有幾個小而美的技巧能顯著提升日常使用體驗。反向調(diào)試。GDB支持記錄程序執(zhí)行軌跡然后反向運行命令是record break demo.c:13 run reverse-continuerecord開啟記錄模式程序運行過的每一條指令都會被記錄下來然后你可以reverse-continue往回走從崩潰點一步步倒著查它是從哪里來的。這個功能對排查“變量為什么變成這個值”這類問題極其好用。代價是record模式運行速度明顯變慢而且指令記錄量大了很吃內(nèi)存適合小范圍復現(xiàn)場景。TUI界面。GDB自帶一個字符界面模式layout src進入后屏幕會分成兩個區(qū)域上面顯示源碼下面顯示命令區(qū)光標跟著當前執(zhí)行行走比純命令行敲list直觀一百倍。用CtrlXA可以在TUI模式和普通模式間切換。gdbinit一句話配置。我每次新建調(diào)試環(huán)境都會寫這么三句set pagination off set confirm off set print pretty onset confirm off省掉了刪除斷點、退出GDB時的確認提問批量操作時能省不少事set print pretty on讓結構體打印時按成員換行排列看復雜數(shù)據(jù)結構清晰得多。還有print自定義美化。調(diào)試C項目時可以給std::vector、std::map這些容器配pretty-printer讓print查看STL容器內(nèi)容變得直觀可讀。我們在某大型項目里給了自定義了十幾條pretty-printer的配置排查復雜數(shù)據(jù)結構問題全靠它否則純靠看地址和內(nèi)存效率不可同日而語。最后再說說core dump的正確打開方式。Linux上默認不生成core文件需要設置ulimit -c unlimited這個命令最好寫進shell的配置文件里否則新開一個終端又得重新設置。我建議是在開發(fā)環(huán)境的日常啟動腳本里加上這一行然后程序崩潰后會生成core.pid文件。等到問題發(fā)生時直接用gdb -c core文件單步回放崩潰現(xiàn)場。這種方式比啟動GDB現(xiàn)跑一遍程序高效得多而且不會改變程序的運行時序多線程程序的崩潰現(xiàn)場也更真實。我在實際項目里還試過給GDB寫一點Python擴展。GDB本身就是支持Python的你可以自定義命令、創(chuàng)建斷點腳本甚至解析日志自動定位可疑點。對簡單場景來說這些可能有點殺雞用牛刀但一旦接觸復雜C系統(tǒng)尤其要批量分析多個崩潰現(xiàn)場時會寫幾條自定義腳本能節(jié)省的時間非?？捎^。寫在最后的個人體會GDB真的是越用越離不開的工具。我自己剛學的時候也覺得命令又多又雜命令行上手成本高但真正用過幾次把它解決掉實際問題后就再也回不去純靠日志猜bug的狀態(tài)了。重點是先把每個場景里最核心的那幾個命令練熟崩潰看bt、斷點看break、單步選next和step、變量看print、多線程看thread apply all bt跑通了這套基本流程你已經(jīng)能應付一大半真實問題了。再往后想進階的話值得研究的方向是反向調(diào)試、TUI界面、Python擴展和core文件自動化分析。尤其是把GDB接入項目的自動化崩潰檢測流程那些在CI里被抓到的崩潰不用等人工介入就能自動拉出崩潰棧這對團隊效率的提升是很明顯的。最后給大家一個建議不要等出了問題才翻GDB手冊找個周末拿自己以前的bug程序練一練把斷點、單步、?；厮荨⑿薷淖兞窟@四個基礎流程走一遍。真正上手一遍之后你會發(fā)現(xiàn)它其實沒有想象中那么難而且能幫你在未來節(jié)省出大量本來要消耗在深夜排查上的時間。 GDB調(diào)試實戰(zhàn)指南：從崩潰定位到多線程排查
前陣子幫同事排查一個線上崩潰程序跑了大半天才掛掛在哪一行完全看不出來日志里最后一條信息還離崩潰點十萬八千里。折騰了半個下午最后上了GDB兩分鐘定位到一處野指針。從那之后我就一直在想Linux下做C/C開發(fā)的人GDB是早晚要邁過去的一道坎早點掌握它后面能省下無數(shù)加班的夜晚。這篇文章不是想給你羅列一大堆命令手冊而是把我實際用GDB排查問題時最常用、最有效的那套東西整理出來包括編譯期就得做對的準備、崩潰現(xiàn)場的分析思路、斷點和單步的精髓、多線程調(diào)試的注意點以及幾個教程里很少寫的坑。無論你是剛接觸Linux開發(fā)的新手還是寫過一段時間但對GDB只停留在“會用start和next”階段的人看完這篇應該都能直接上手解決實際項目里的問題。1. 為什么Linux下調(diào)試離不開GDB1.1 日志排查的邊界很多人寫程序習慣用printf遇到bug就打日志。日志確實有用尤其適合排查業(yè)務邏輯問題。但有一類問題靠日志很難搞典型的就是段錯誤、棧溢出、非法內(nèi)存訪問。這類崩潰偶爾復現(xiàn)甚至只在壓力測試時出現(xiàn)你根本不知道在哪個函數(shù)、哪一條指令觸發(fā)了它打再多的printf都是盲人摸象。還有數(shù)據(jù)競爭這類問題兩個線程同時改一個變量日志順序看起來完全正常但結果就是不對。這時候你需要的是逐行審視代碼在內(nèi)存里到底干了什么需要看到每一個變量的實際值、每一塊內(nèi)存的實時內(nèi)容而GDB的核心價值就在這里它能讓你把程序“暫?！痹谌我庖粋€你關心的時刻然后你就能看清這個時刻的所有細節(jié)。我個人的習慣是邏輯問題先查日志查不到就用GDB跨過“靠猜加盲目打印”的階段。實際項目里GDB解決頻率最高的問題就三類——崩潰閃退、邏輯結果不正確、多線程跑飛每一類GDB都有成熟的調(diào)試套路。1.2 GDB到底能做什么GDB全名GNU Debugger是Linux平臺上最主流的調(diào)試器。它的能力要從三個層面看控制執(zhí)行斷點、單步、繼續(xù)運行到指定位置、跳過或進入函數(shù)觀察現(xiàn)場打印變量、查看?；厮?、查看內(nèi)存、查看寄存器、查看線程和進程狀態(tài)修改現(xiàn)場運行時修改變量值、強制函數(shù)返回、跳過某段代碼用這個能模擬各種邊界條件我見過有人用GDB十幾年就記住了三個命令break、run、print。這三個確實能解決一部分問題但如果你只知道這三個遇到斷點打不上、變量被優(yōu)化掉、多線程死鎖、core文件解析不了的時候就會卡住。所以后面我會把常用的場景串起來講不只是堆命令。注意不需要把GDB幾百個命令都背下來真正的核心命令不超過二十個熟練使用它們已經(jīng)能覆蓋絕大多數(shù)調(diào)試場景了。2. 準備工作編譯期就要做對的事2.1 -g參數(shù)決定了你調(diào)的是什么GDB調(diào)試時依賴調(diào)試信息來建立“源碼行號 ? 二進制指令 ? 變量地址”之間的對應關系。要讓GDB能告訴你“程序崩在第3個文件第27行”前提是編譯時加了-g參數(shù)gcc -g -o demo demo.c-g會讓編譯器在二進制文件里生成一個調(diào)試信息段包含源碼行號、變量名、函數(shù)名、參數(shù)類型這些元數(shù)據(jù)。沒有這個信息GDB看到的全是十六進制地址和匯編指令雖然也能調(diào)但難度直接上升一個臺階。另外一個容易被忽視的參數(shù)是-g3。它比-g多包含宏定義信息如果你調(diào)試的程序里用到宏想用info macro查看宏的展開結果就得在-g后面加一個3。我的建議是項目調(diào)試版本統(tǒng)一用-g3編譯成本差別不大。還有一點很多人忽略了編譯器優(yōu)化對調(diào)試體驗的影響見下一節(jié)。2.2 優(yōu)化選項與調(diào)試信息的恩怨編譯時常用的優(yōu)化選項有-O0、-O1、-O2。優(yōu)化開得越高編譯器的重排、內(nèi)聯(lián)、寄存器變量優(yōu)化就越激進最終產(chǎn)出的機器碼和你寫的源碼之間差異就越大。我用一個實際踩過的坑說明某個問題在-O0下正常、在-O2下必現(xiàn)于是我在發(fā)布版本上直接跑GDB想定位結果print某個局部變量提示“value optimized out”單步走的時候發(fā)現(xiàn)代碼在odd跳步你明明在源碼第10行執(zhí)行完第11行之后居然跳到了第15行。這不是GDB壞了而是編譯器把中間的計算過程優(yōu)化掉了有些變量只存在于寄存器里甚至直接被常數(shù)替代掉了。所以我的建議很明確排查崩潰類問題時先用-O0編譯一個調(diào)試版本問題在調(diào)試版本能復現(xiàn)就先在調(diào)試版本上定位如果問題只在-O2下復現(xiàn)也不要硬剛優(yōu)化代碼試著添加-fno-omit-frame-pointer保留棧幀指針并且在關鍵函數(shù)上用__attribute__((optimize(O0)))做局部關閉優(yōu)化。記住一個原則先在未優(yōu)化版本上把邏輯調(diào)試清楚再去分析優(yōu)化版本的特殊行為而不是直接在高優(yōu)化級別下硬調(diào)。還有一個參數(shù)值得了解-fno-stack-protector。有些發(fā)行版默認開了棧保護越界時程序會主動abort而不是崩在真正越界的代碼里這有時會誤導排查方向。定位棧溢出時先關掉它往往能看到更原始的崩潰位置。2.3 啟動GDB的幾種姿勢GDB不僅僅是“gdb ./program”這一種玩法實際工作中我常用的有四種場景命令適用情況普通調(diào)試gdb ./demo程序能穩(wěn)定復現(xiàn)問題傳參調(diào)試gdb --args ./demo arg1 arg2程序依賴啟動參數(shù)掛載進程gdb -p 23456程序在跑且不好重啟分析coredumpgdb ./demo core.12345程序崩潰后有core文件掛載進程這個功能特別實用生產(chǎn)環(huán)境出問題不想立刻重啟進程時可以用gdb -p加到進程上抓現(xiàn)場。但注意掛上去之后進程是暫停的別忘了在結尾用detach把它放掉否則進程就一直卡住了。分析core文件是我最推薦的崩潰排查方式后面第3節(jié)再展開聊。2.4 自動化批處理.gdbinit與-batch模式日常調(diào)試總有反復輸入幾條固定命令的場景比如啟動后先設置斷點、然后打印參數(shù)。你可以在當前目錄或用戶目錄寫一個.gdbinit文件GDB啟動時會自動讀取并執(zhí)行里面的命令。下面是我的一個示例set pagination off set print pretty on set print thread-events offset pagination off很關鍵它關閉了GDB的分頁提示否則輸出一多就出現(xiàn)“---Type to continue”卡在那里批處理腳本里直接就沒法跑了。還有一種用法是在腳本里跑非交互式調(diào)試。比如定時任務里程序崩了第二天想快速拿到棧直接用一行命令輸出然后退出gdb -batch -ex run -ex bt --args ./demo-batch表示非交互模式逐條執(zhí)行-ex參數(shù)指定的命令全跑完自動退出。我在寫自動化測試腳本時經(jīng)常用它批量檢查崩潰棧不用人工干預。3. 核心調(diào)試實操從一個崩潰程序說起3.1 程序崩潰后第一件事看?；厮菹瓤匆粋€能穩(wěn)定復現(xiàn)段錯誤的例子后面就用它來演示GDB的核心操作。源碼是這樣的#include stdio.h #include string.h char *safe_strcpy(char *buf, const char *src) { if (src NULL) { strcpy(buf, unknown); } else { strcpy(buf, src); } return buf; } int main() { char buf[32]; strcpy(buf, abcdefg); safe_strcpy(buf, NULL); printf(result: %s\n, buf); return 0; }我故意讓strcpy收到NULL指針編譯運行后直接段錯誤。這種問題用日志幾乎沒法查因為你根本不知道哪個函數(shù)傳進了NULL。用GDB復現(xiàn)的流程是gcc -g -O0 -o demo demo.c gdb ./demo進到GDB后輸入run程序跑起來崩潰Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58這里GDB已經(jīng)告訴你崩在strcpy的匯編實現(xiàn)里。但這還遠遠不夠重要的問題是是誰調(diào)用了strcpy參數(shù)傳進來的src到底是不是NULL此時輸入bt也就是backtrace查看當前線程的函數(shù)調(diào)用棧(gdb) bt #0 0x00007ffff7e2b3c8 in __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/strcpy-sse2.S:58 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 #2 0x0000000000401245 in main () at demo.c:15這一下就清楚了。?；厮輹谐鰪谋罎r的最內(nèi)層函數(shù)到最外層函數(shù)的完整調(diào)用鏈每一幀還附帶關鍵參數(shù)值。你看第1幀里safe_strcpy的src0x0直接就露出來了NULL指針的元兇馬上鎖定。bt之后一般搭配的是frame命令切到指定棧幀然后查看局部變量(gdb) frame 1 #1 0x0000000000401200 in safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:9 9 strcpy(buf, unknown); (gdb) info args buf 0x7fffffffdf50 abcdefg src 0x0記住這個流程化打法崩了之后先看bt拿到整個調(diào)用鏈再切frame到目標幀查看參數(shù)和局部變量。80%的崩潰問題靠這一步就能定位出原因。3.2 斷點的正確打開方式崩潰排查只是GDB的一面另一面是主動出擊程序還沒崩但你知道某個函數(shù)可能有問題想在它被調(diào)用時停下來看看。這時候用break設置斷點。GDB里斷點的核心命令其實就幾種break safe_strcpy # 在函數(shù)入口打斷點 break demo.c:8 # 在源文件第8行打斷點 break demo.c:8 if len 0 # 條件斷點滿足條件才暫停條件斷點非常實用。比如一個循環(huán)跑一萬次第9000次結果不對你不想被斷點打斷9000次直接寫break demo.c:8 if i 9000程序會在i等于9000的時候才停下來。這就是硬件/軟件斷點加上條件判斷的配合。還有一個我經(jīng)常用的命令是tbreak臨時斷點只觸發(fā)一次自動刪除。比如只是想停在一個位置看一眼不想讓斷點殘留用這個就很干凈。查看和刪除斷點info breakpoints # 列出所有斷點及其狀態(tài) delete 1 # 刪除編號為1的斷點 disable 2 # 禁用編號為2的斷點保留位置 enable 2 # 重新啟用實踐中我見過有人把幾十個斷點全堆在代碼里斷點太多會互相干擾每個暫停都會檢查一遍條件嚴重影響運行速度。我的習慣是一次只保留三到五個斷點解決完一批馬上刪掉或禁用。3.3 單步執(zhí)行next、step、until怎么選斷點命中后最重要的是逐行看清程序的執(zhí)行過程。GDB里三個最常見的單步命令長的很像但語義差別很大next執(zhí)行當前行遇到函數(shù)調(diào)用直接跳過也叫“單步跳過”step執(zhí)行當前行如果遇到函數(shù)調(diào)用就進去也叫“單步進入”until在循環(huán)里一直執(zhí)行直到到達指定行號或退出循環(huán)用demo舉例子。我在main函數(shù)第12行strcpy(buf, abcdefg)處打斷點run進去后(gdb) next 13 safe_strcpy(buf, NULL); (gdb) next Program received signal SIGSEGV, Segmentation fault.第一次next執(zhí)行完strcpy第二次next直接步入safe_strcpy的調(diào)用結果就崩了。注意next在遇到函數(shù)調(diào)用時是整體執(zhí)行完再停到下一條語句的所以如果函數(shù)內(nèi)部崩潰next會直接帶著你看到崩潰現(xiàn)場。如果我想看safe_strcpy內(nèi)部是怎么走的要用step(gdb) break demo.c:12 (gdb) run Breakpoint 1, main () at demo.c:12 12 strcpy(buf, abcdefg); (gdb) next 13 safe_strcpy(buf, NULL); (gdb) step safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5 5 if (src NULL) {step把你帶進了safe_strcpy函數(shù)體內(nèi)。之后第6行的strcpy(buf, unknown)如果真的執(zhí)行又會二次步入庫函數(shù)內(nèi)部。如果想跳出當前函數(shù)回到調(diào)用者用finish(gdb) finish Run till exit from #0 safe_strcpy (buf0x7fffffffdf50 abcdefg, src0x0) at demo.c:5finish是“執(zhí)行完當前函數(shù)然后停在返回處”非常常用尤其在盯著一個函數(shù)內(nèi)部執(zhí)行完之后的調(diào)用現(xiàn)場時。until的典型場景是循環(huán)。你想在一個循環(huán)里快速執(zhí)行到某個位置但又不想一行一行next按幾百次直接until demo.c:20就能一口氣跑到第20行。注意使用step進入庫函數(shù)時GDB經(jīng)常會一頭扎進printf、strcpy這類C庫的內(nèi)部實現(xiàn)里面全是匯編對排查業(yè)務邏輯沒啥幫助。遇到這種情況直接finish跳出去或者干脆用next避免進入。3.4 變量、內(nèi)存與寄存器看變量最常用的是print命令后面跟變量名或表達式(gdb) print src $1 (char *) 0x0 (gdb) print buf $2 0x7fffffffdf50 abcdefg (gdb) print/x 12345 $3 0x3039print的格式控制符很重要不同場景要用不同的格式p/x 按十六進制看指針和地址p/d 按十進制看整數(shù)p/c 按字符看字節(jié)p/s 按字符串看內(nèi)容p *ptrcount 看指針指向的連續(xù)count個元素比如看到指針地址是0x7fffffffdf50懷疑它指向的內(nèi)存被寫壞了想看看它前16個字節(jié)的內(nèi)容(gdb) x/16bx 0x7fffffffdf50 0x7fffffffdf50: 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x00 0x7fffffffdf58: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000x61到0x67是abcdefg的ASCII碼后面的0x00是被strcpy寫入的字符串終止符。x命令的格式是x/長度格式單位大小 地址b是單字節(jié)、w是四字節(jié)、g是八字節(jié)。這個組合能幫你看清任意內(nèi)存區(qū)域的實際內(nèi)容排查越界寫、內(nèi)存覆寫時是神器。查看寄存器用info registers調(diào)試匯編和棧問題時有用(gdb) info registers rip rsp rbp rip 0x7ffff7e2b3c8 rsp 0x7fffffffdf48 rbp 0x7fffffffdf60在實際調(diào)試里打印變量的優(yōu)先級高于看寄存器后者主要用于底層匯編分析、函數(shù)調(diào)用約定排查這類場景。4. 多線程調(diào)試崩潰只是表象4.1 定位死鎖和數(shù)據(jù)競爭多線程程序出問題時經(jīng)常會發(fā)現(xiàn)單獨的某個線程看起來都“正常”但整體結果不對。GDB提供了查看所有線程并切換線程的能力。用一個最簡單的多線程自增程序演示兩個線程同時對共享變量做自增缺少鎖保護最終結果大概率小于2000。編譯時注意加lpthreadgcc -g -O0 -o demo_thread demo_thread.c -lpthreadGDB里看到線程列表(gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7dbc740 (LWP 23456) demo_thread main () at demo_thread.c:23 2 Thread 0x7ffff75bc700 (LWP 23457) demo_thread worker (arg0x0) at demo_thread.c:10帶*號的是當前調(diào)試線程。切換到線程2(gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff75bc700 (LWP 23457))]注意切換線程后GDB會暫停在那個線程當前執(zhí)行的指令上。接下來可以用bt查看這個線程的棧用info locals看它的局部變量。要同時看所有線程的棧用(gdb) thread apply all bt這條命令在定位死鎖時特別管用。死鎖的典型特征是多個線程各自卡在不同的鎖等待上你用thread apply all bt能看到每個線程停在哪個鎖函數(shù)里比如線程A卡在pthread_mutex_lock占有鎖X線程B卡在pthread_mutex_lock占有鎖Y而A在等Y、B在等X死鎖閉環(huán)立刻顯現(xiàn)。確認了數(shù)據(jù)競爭下一步就要靠watch命令監(jiān)視某個變量何時被修改(gdb) watch shared Hardware watchpoint 2: shared (gdb) continue每當shared的值發(fā)生變化GDB就會暫停并且打印先前的值和新的值。連續(xù)watch幾次你就能看到兩個線程交錯修改shared的現(xiàn)場數(shù)據(jù)競爭引發(fā)的丟更新操作就暴露出來了。4.2 如何跟蹤fork出的子進程多進程程序用fork創(chuàng)建子進程很常見GDB默認只跟蹤父進程子進程會脫離調(diào)試。如果你想調(diào)試子進程需要在fork之前設置set follow-fork-mode child set detach-on-fork offset follow-fork-mode child讓GDB在fork后自動跟隨子進程set detach-on-fork off讓父進程繼續(xù)保持被調(diào)試狀態(tài)兩個進程都在GDB控制下可以用info inferiors命令查看和管理多條進程上下文。這里有個經(jīng)驗多進程調(diào)試時建議先搞清問題出在哪個進程再決定跟著誰。不加區(qū)分地同時調(diào)試兩個進程會頻繁被另一個進程的斷點打斷調(diào)試效率反而暴跌。實際項目里我一般先只跟父進程如果確認問題在子進程再切過去。4.3 多線程調(diào)試的個人經(jīng)驗多線程調(diào)試容易踩的坑比單線程多得多分享幾個壓箱底的經(jīng)驗。第一個是線程切換和斷點之間的配合。默認情況下你在主線程設置斷點后運行只有主線程命中斷點會暫停其他線程命中相同斷點也會各自暫停。但有的時候你只想讓指定線程停下來set scheduler-locking on這條命令開啟調(diào)度鎖GDB暫停一個線程后其他線程也跟著暫停不會被單獨放跑。在排查數(shù)據(jù)競爭時這個尤其重要否則你在觀察線程A時線程B卻在后臺瘋狂跑變量內(nèi)容一直在變你根本看不準。第二個是開線程事件開關。GDB默認會在每個線程創(chuàng)建和退出時打印一堆事件信息調(diào)試復雜程序時非常刷屏set print thread-events off第三個是別急著在懷疑的代碼上單步。多線程程序單步執(zhí)行會影響時序很多時候多線程bug一旦進入單步就復現(xiàn)不出來了。我的經(jīng)驗是先用日志和perf工具縮小范圍明確到具體幾行代碼后再把GDB的斷點精準設在那幾行上用continue讓程序高速跑到斷點附近而不是從main開始一步步走。5. 常見問題與排查技巧實錄5.1 常見問題速查表把大家問得最多、我自己也踩過的場景整理成一個表格按圖索驥用起來非常方便現(xiàn)象常見原因排查手段崩在庫函數(shù)里參數(shù)非法多為空指針bt看調(diào)用棧frame切到上層print變量顯示optimized out編譯優(yōu)化把變量優(yōu)化掉了改用-O0編譯或?qū)ｍ楆P閉優(yōu)化斷點打在函數(shù)上不生效斷點處被編譯器內(nèi)聯(lián)掉改成在文件行號打斷點程序一run就退出常因找不到動態(tài)庫或參數(shù)錯誤用info sharedlibrary和set args檢查core文件gdb讀不出來生成core時沒保存可執(zhí)行文件確保core和對應可執(zhí)行文件版本匹配多線程加斷點后程序卡死斷點命中后進入鎖等待用scheduler-locking onbt看鎖狀態(tài)崩潰在-O2下必現(xiàn)-O0正常優(yōu)化改變了執(zhí)行路徑單獨用-fno-omit-frame-pointer復現(xiàn)分析5.2 調(diào)試時我見過最坑的幾個現(xiàn)象先說“變量被優(yōu)化掉”。這個在大型代碼庫里特別常見尤其release版本。你明明在源碼里能看到那個變量print卻告訴你optimized out。我第一次遇到時以為GDB壞了后來才明白是編譯器把變量直接揉進了表達式里根本沒有分配內(nèi)存位置。排查思路是一不要在高優(yōu)化級別下浪費時間先換-O0二不要指望所有變量都非得能print改成在函數(shù)入口用info args看參數(shù)或者特意留一個全局變量記錄關鍵狀態(tài)。再說“斷點打不上去”。有的時候你在函數(shù)名上breakGDB卻提示“No symbol table is loaded”或者斷點設到了一個內(nèi)存地址但永遠不命中。最常見原因是函數(shù)被編譯器內(nèi)聯(lián)了斷點實際對應不到入口。解決辦法很簡單要么在源碼行號上打斷點要么臨時用noinline屬性阻止內(nèi)聯(lián)__attribute__((noinline)) static int helper(int x) { return x * 2; }第三個坑是core文件版本不匹配。GDB要求core文件和產(chǎn)生它的可執(zhí)行文件完全匹配否則bt出來全是“No symbol table info available”這種鬼話。很多人程序崩了只把core拷回來不拷可執(zhí)行文件結果根本看不出什么問題。正確的搬家姿勢是core文件和對應版本的二進制一起打包拿回來。5.3 一些提升效率的小技巧除了大塊的調(diào)試技能還有幾個小而美的技巧能顯著提升日常使用體驗。反向調(diào)試。GDB支持記錄程序執(zhí)行軌跡然后反向運行命令是record break demo.c:13 run reverse-continuerecord開啟記錄模式程序運行過的每一條指令都會被記錄下來然后你可以reverse-continue往回走從崩潰點一步步倒著查它是從哪里來的。這個功能對排查“變量為什么變成這個值”這類問題極其好用。代價是record模式運行速度明顯變慢而且指令記錄量大了很吃內(nèi)存適合小范圍復現(xiàn)場景。TUI界面。GDB自帶一個字符界面模式layout src進入后屏幕會分成兩個區(qū)域上面顯示源碼下面顯示命令區(qū)光標跟著當前執(zhí)行行走比純命令行敲list直觀一百倍。用CtrlXA可以在TUI模式和普通模式間切換。gdbinit一句話配置。我每次新建調(diào)試環(huán)境都會寫這么三句set pagination off set confirm off set print pretty onset confirm off省掉了刪除斷點、退出GDB時的確認提問批量操作時能省不少事set print pretty on讓結構體打印時按成員換行排列看復雜數(shù)據(jù)結構清晰得多。還有print自定義美化。調(diào)試C項目時可以給std::vector、std::map這些容器配pretty-printer讓print查看STL容器內(nèi)容變得直觀可讀。我們在某大型項目里給了自定義了十幾條pretty-printer的配置排查復雜數(shù)據(jù)結構問題全靠它否則純靠看地址和內(nèi)存效率不可同日而語。最后再說說core dump的正確打開方式。Linux上默認不生成core文件需要設置ulimit -c unlimited這個命令最好寫進shell的配置文件里否則新開一個終端又得重新設置。我建議是在開發(fā)環(huán)境的日常啟動腳本里加上這一行然后程序崩潰后會生成core.pid文件。等到問題發(fā)生時直接用gdb -c core文件單步回放崩潰現(xiàn)場。這種方式比啟動GDB現(xiàn)跑一遍程序高效得多而且不會改變程序的運行時序多線程程序的崩潰現(xiàn)場也更真實。我在實際項目里還試過給GDB寫一點Python擴展。GDB本身就是支持Python的你可以自定義命令、創(chuàng)建斷點腳本甚至解析日志自動定位可疑點。對簡單場景來說這些可能有點殺雞用牛刀但一旦接觸復雜C系統(tǒng)尤其要批量分析多個崩潰現(xiàn)場時會寫幾條自定義腳本能節(jié)省的時間非?？捎^。寫在最后的個人體會GDB真的是越用越離不開的工具。我自己剛學的時候也覺得命令又多又雜命令行上手成本高但真正用過幾次把它解決掉實際問題后就再也回不去純靠日志猜bug的狀態(tài)了。重點是先把每個場景里最核心的那幾個命令練熟崩潰看bt、斷點看break、單步選next和step、變量看print、多線程看thread apply all bt跑通了這套基本流程你已經(jīng)能應付一大半真實問題了。再往后想進階的話值得研究的方向是反向調(diào)試、TUI界面、Python擴展和core文件自動化分析。尤其是把GDB接入項目的自動化崩潰檢測流程那些在CI里被抓到的崩潰不用等人工介入就能自動拉出崩潰棧這對團隊效率的提升是很明顯的。最后給大家一個建議不要等出了問題才翻GDB手冊找個周末拿自己以前的bug程序練一練把斷點、單步、?；厮荨⑿薷淖兞窟@四個基礎流程走一遍。真正上手一遍之后你會發(fā)現(xiàn)它其實沒有想象中那么難而且能幫你在未來節(jié)省出大量本來要消耗在深夜排查上的時間。