用gdb分析coredump的一些技巧
前幾天我們正在運(yùn)營(yíng)的一款產(chǎn)品發(fā)生了崩潰，我花了兩天嘗試用 gdb 分析了 coredump ，雖然最后還是沒(méi)能找到 bug ，但還是覺(jué)得應(yīng)該做一些總結(jié)。
產(chǎn)品是基于 skynet 開(kāi)發(fā)的，由于歷史原因，它基于的是 skynet 1.0 之前 2015 年中的一個(gè)版本，由于這兩年一直沒(méi)出過(guò)什么問(wèn)題，所以維護(hù)人員懈怠而沒(méi)有更新。
崩潰的時(shí)候，關(guān)于 Lua 部分的代碼缺少調(diào)試符號(hào)信息，這加大了分析難度。現(xiàn)在的 skynet 在編譯 lua 時(shí)，加入了 -g 選項(xiàng)，這應(yīng)該可以幫助未來(lái)出現(xiàn)類似問(wèn)題時(shí)更好的定位問(wèn)題。
導(dǎo)致代碼崩潰的直接原因是 rip 指向了一個(gè)數(shù)據(jù)段的地址，準(zhǔn)確的說(shuō)，跳轉(zhuǎn)到了當(dāng)前工作線程擁有的 lua 虛擬機(jī)的主線程 L 那里。
發(fā)現(xiàn)這條線索很容易，skynet 的其它部分是有調(diào)試符號(hào)的，可以在崩潰的調(diào)用棧上看到，服務(wù)的 callback 函數(shù)的 ud 和崩潰地址一致，而 lua 服務(wù)的 ud 正是 L 。用 gdb 的 p ( lua_State *)地址 查看這個(gè)結(jié)構(gòu)，也能觀察到這個(gè)數(shù)據(jù)結(jié)構(gòu)的內(nèi)容正是一個(gè) lua_State 。
由于用 bt 查看的調(diào)用棧是不正常的，所以可以斷定在函數(shù)調(diào)用鏈的過(guò)程中應(yīng)該是發(fā)生了某種錯(cuò)誤改寫(xiě)了 C 棧的內(nèi)容。在這種情況下，gdb 多半靠猜測(cè)來(lái)重建調(diào)用鏈(就是用 bt 看到的那些)。
現(xiàn)代編譯器經(jīng)過(guò)優(yōu)化代碼之后， C 棧上已經(jīng)沒(méi)有 stack frame 的基地址了，所以現(xiàn)在不能簡(jiǎn)單的看堆棧的數(shù)據(jù)內(nèi)容來(lái)推測(cè) stack frame 。也就是經(jīng)過(guò)優(yōu)化的代碼不一定適用 rbp 來(lái)保存 stack frame ，它也不一定入棧。對(duì)于 gcc ，這個(gè)優(yōu)化策略是通過(guò) -fomit-frame-pointer 開(kāi)啟的，只要用 -O 編譯，就一定打開(kāi)的。在 stack 本身出問(wèn)題時(shí)，gdb 的猜測(cè)很可能不準(zhǔn)確，人工來(lái)猜或手工補(bǔ)全或許更靠譜一些。方法就是先用 x/40xg $rsp 打印出 C stack 的內(nèi)容，然后觀察確定 stack 上的哪些數(shù)據(jù)落在代碼段上。所有有函數(shù)調(diào)用的地方，一定有處于代碼段上的某處返回地址指針。
主程序的代碼段一般都地址偏低，動(dòng)態(tài)鏈入的代碼段可以用 info sharedlibrary 來(lái)查看。返回地址肯定是落在函數(shù)代碼的內(nèi)部，而肯定不會(huì)是函數(shù)入口，而這些地址除了函數(shù)調(diào)用外，都不可能用正常的 C 代碼生成出來(lái)，所以識(shí)別性很強(qiáng)，不會(huì)有歧義。
如果覺(jué)得某個(gè)指針是函數(shù)返回地址，可以用 x/10i 地址 來(lái)反匯編確認(rèn)。
但是需要注意的是，即使在 C stack 上發(fā)現(xiàn)一個(gè)函數(shù)返回地址，并不說(shuō)明這個(gè)函數(shù)調(diào)用尚未返回。它只能說(shuō)明這個(gè)函數(shù)至少被調(diào)用過(guò)。這是因?yàn)椋瑓R編在 call 一個(gè)函數(shù)時(shí)，會(huì)把當(dāng)前調(diào)用處的地址壓棧。而調(diào)用結(jié)束后，ret 指令返回只是修改了 rsp 這個(gè)棧指針，而數(shù)據(jù)本身是殘留在棧上的。這也是為什么 gdb 有時(shí)候也會(huì)猜錯(cuò)。
在這次的案例里，崩潰發(fā)生在執(zhí)行跳轉(zhuǎn)到了數(shù)據(jù)段，這種情況多半是因?yàn)?call 指令調(diào)用的是一個(gè)間接引用，在 C 層面來(lái)看，就是調(diào)用了一個(gè)函數(shù)指針。這種情況下，跳轉(zhuǎn)地址肯定還在寄存器里。用 info registers 可以查看。(注：在 64bit 平臺(tái)下，查看寄存器內(nèi)容非常重要，因?yàn)?64bit 下，函數(shù)調(diào)用的前四個(gè)參數(shù)是通過(guò)寄存器 rdi rsi 傳遞而非堆棧，往往需要結(jié)合 disass 反匯編看代碼去推算。)
當(dāng)然，按 lua 自己的正常邏輯，是不可能把 L 作為一個(gè)函數(shù)指針來(lái)調(diào)用的。按我的猜測(cè)，這里出錯(cuò)比較大的可能是 longjmp 的時(shí)候數(shù)據(jù)出錯(cuò)，恢復(fù)了錯(cuò)誤的寄存器。btw, setjmp 在生成 jmp_buf 時(shí)，對(duì)于 rsp rbp 這類很可能用于地址的寄存器，crt 做了變形(mangling)處理，所以很難簡(jiǎn)單的靠寫(xiě)越界寫(xiě)出一個(gè)巧合的錯(cuò)誤值。
對(duì)于調(diào)試崩潰在 lua 內(nèi)部的情況，比較關(guān)鍵的線索通常是 L 本身的狀態(tài)。因?yàn)闃I(yè)務(wù)的主流程其實(shí)是用 lua vm 驅(qū)動(dòng)的，L 的 callinfo 也就是 lua 的 stack frame 信息更多。
對(duì)于 skynet ，在正常運(yùn)行的時(shí)候通常會(huì)有兩個(gè)活動(dòng)的 L 。一個(gè)是主線程，用來(lái)分發(fā)消息;但消息本身是在一個(gè)獨(dú)立的 coroutine 中進(jìn)行的。以上可以確定主線程，而子線程的 L 可以在寄存器和 stack frame 里找。由于沒(méi)有調(diào)試符號(hào)，所以可以靠猜來(lái)尋找，這并不算太麻煩。要確定一個(gè)地址是否是 L ，只需要查看 L->l_G 看是否和前面找到的主線程 L 的對(duì)應(yīng)值是否相同。
在缺少調(diào)試符號(hào)的情況下，會(huì)發(fā)現(xiàn) lua 下的一些內(nèi)部數(shù)據(jù)結(jié)構(gòu) gdb 無(wú)法識(shí)別。這個(gè)時(shí)候可以用 add-symbol-file 來(lái)導(dǎo)入需要的結(jié)構(gòu)信息。方法是加上 -g 重新編譯一下 lua ，把一些包含這些結(jié)構(gòu)的文件，例如 ldo.o 加進(jìn)來(lái)。
我在分析這次的問(wèn)題時(shí)，寫(xiě)了腳本查看兩個(gè) L 的 lua 調(diào)用棧，這些腳本只要對(duì) lstate.h 里的 callinfo 數(shù)據(jù)結(jié)構(gòu)熟悉就很容易寫(xiě)出來(lái)。lua 的調(diào)試信息很豐富，找到源文件名和行號(hào)都很容易。另外，L 棧頂?shù)臄?shù)據(jù)是什么也是重要的線索，可以推導(dǎo)出崩潰發(fā)生時(shí) Lua 的狀態(tài)。
這次我們崩潰的程序最后停在主線程的 resume 調(diào)用子線程上。子線程調(diào)用了 skynet.sleep ，也就是最后把 "SLEEP", session 通過(guò) yield 傳給了主線程。這些要傳出的量可以在子線程的 L->top 上查到。雖然 lua 本身已經(jīng)把值 pop 出去了，但 pop 本身是不清空棧的，只是調(diào)整了棧頂指針，所以在 gdb 下依然可見(jiàn)。主線程也接收到了傳過(guò)來(lái)的數(shù)據(jù)，數(shù)據(jù)棧上可見(jiàn)。
不過(guò)這次的吊詭之處在于，lua 線程間拷貝數(shù)據(jù)這個(gè)過(guò)程是在 lcorolib.c 中的 auxresume 函數(shù)中執(zhí)行的，在 luaB_coresume 里還需要在結(jié)果中插入一個(gè) boolean 。而我在 coredump 數(shù)據(jù)中發(fā)現(xiàn)了拷貝過(guò)程已經(jīng)完成，但是 boolean 卻沒(méi)有壓入。那么事故發(fā)生點(diǎn)只可能在兩者之間。不過(guò)在 auxresume 返回到后續(xù) push boolean 之間只有幾行匯編代碼，絕對(duì)不可能出錯(cuò)。
唯一能解釋的就是在 lua_resume 期間，子線程運(yùn)行的流程破壞了 C 的 stackframe ，讓 auxresume 沒(méi)能正確的返回到調(diào)用它的 luaB_coresume 中。但怎樣才能制造出這種情況，我暫時(shí)沒(méi)有想法。
在 C 層面制造出崩潰的可能性并不是很多，數(shù)據(jù)越界是一類常見(jiàn)的 bug (這次并不像);另一類是內(nèi)存管理出錯(cuò)，比如對(duì)同一個(gè)指針 free 多次，導(dǎo)致內(nèi)存管理器出錯(cuò)，把同一個(gè)地址分配給兩個(gè)位置，導(dǎo)致兩個(gè)對(duì)象地址重疊。后一類問(wèn)題能干擾到 C 的 stack frame 可能性比較小，除非有堆上的對(duì)象指針指向了棧地址，然后并引用。這次的 bug 中，最打的線索是 L->errorJmp ，也就是 lua 線程中指向恢復(fù)點(diǎn)的 jmp_buf ，它是在 C 棧上的。
L 中有一些相關(guān)變量可以推測(cè) resume/yield/pcall 等的執(zhí)行狀態(tài)： L->nny L->nCcalls L->ci->callstatus 等都是。我分析的結(jié)果是在 auxresume 返回后，沒(méi)有繼續(xù)運(yùn)行 luaB_coresume 中的 push boolean 過(guò)程，卻又運(yùn)行了新的一輪 luaD_pcall ，導(dǎo)致了最終的崩潰。這可以通過(guò) L 的 errorJmp 的 status 得到一定的佐證。不過(guò) C stack 上沒(méi)有 luaB_coresume 的返回地址比較難解釋，只能說(shuō)是可能被錯(cuò)誤的運(yùn)行流程覆蓋掉了。
gc 會(huì)是觸發(fā) bug 的多發(fā)點(diǎn)，因?yàn)?gc 是平行于主流程同步進(jìn)行的。這次崩潰點(diǎn)的子線程的 lua 棧幀停留在 yield 函數(shù)上，在此之前也的確調(diào)用了 gc step 。但是，我們可以通過(guò)查閱 L 的 gcstate 變量查看 gc 處于什么階段。在這次的事發(fā)現(xiàn)場(chǎng)，可以看到 gcstate 為 GCSpropagate 也就是 mark 階段，所以并不會(huì)引發(fā)任何 __gc 流程，也沒(méi)有內(nèi)存釋放。
結(jié)論：對(duì)于 bug ，暫時(shí)沒(méi)有結(jié)論。不過(guò)對(duì)于調(diào)試 lua 編寫(xiě)的程序，還是積累了一些經(jīng)驗(yàn)：
- 一定要在編譯 lua 時(shí)加 -g ，雖然 lua 本身出嚴(yán)重 bug 的可能性極低，但可以方便在出問(wèn)題時(shí)用 gdb 分析。
- 在 gdb 中查看 lua 的調(diào)用棧很有意義，分析 L->ci 很容易拿到調(diào)用棧信息。
- 記得查看一下 lua 的數(shù)據(jù)棧內(nèi)容，包括已經(jīng) pop 出去，但還殘留在內(nèi)存中的數(shù)據(jù)，可以幫助分析崩潰時(shí)的狀態(tài)。
- 記得查看 L 中保留的 gcstate GCdebt 等 gc 相關(guān)變量，可以用于推斷 lua gc 的工作狀態(tài)。
- L 中的 nny nCcalls errorJmp 可以幫助確定 lua 到 C 的調(diào)用層次。注意：一個(gè) yield 狀態(tài)的 coroutine ，errorJmp 指針應(yīng)該為 NULL 。
另外，gdb 分析 skynet 可以從下面的線索入手：
- context 對(duì)象里能找到當(dāng)前服務(wù)的地址、最后一個(gè)向外提起的請(qǐng)求的 session 、接收過(guò)多少條消息等。結(jié)合 log 文件來(lái)看會(huì)有參考價(jià)值。
- 如果想找到內(nèi)存中其它的服務(wù)對(duì)象(非當(dāng)前線程上活動(dòng)的)，可以試試 p *H 。 H 是個(gè)數(shù)組，定義在 skynet_handle.c 中，里面有所有服務(wù)的地址。
- 如果想找到內(nèi)存中待喚醒的 timer ，可以試試 p *TI 。它定義在 skynet_timer.c 中。
