今天一早到了公司，策劃就和我說，前幾天出過問題的那台伺服器，玩家又登陸不上遊戲了。
上去一看，又是cpu使用100%。這問題最近經常出現，又不好查，就乾脆讓運維先別重啟了，直接上線除錯。
一開始以為是lua指令碼的死迴圈，後來才發現原來是底層的定時器問題。查了一整個上午，學到了一些gdb的東西，這裡記錄一下。
1、使用gdb除錯正在執行的程式：
先使用top或者ps命令，查出程序的id。
然後使用：
gdb 程式名 程序id
可以看到attaching to program:***,process 18675這樣的輸出，表示已經附上程序開始除錯。
對於多執行緒，可以先列出執行緒的資訊
(gdb) info thread
得到執行緒的序號
9
thread
0xb7fb1b90 (lwp 18676) 0x0073f402
in __kernel_vsyscall ()
8thread
0xb75b0b90 (lwp 18677) 0x0073f402
in __kernel_vsyscall ()
7thread
0xb6bafb90 (lwp 18678) 0x0073f402
in __kernel_vsyscall ()
6thread
0xb61aeb90 (lwp 18679) 0x0073f402
in __kernel_vsyscall ()
5thread
0xb57adb90 (lwp 18680) 0x0073f402
in __kernel_vsyscall ()
4thread
0xb4dacb90 (lwp 18681) 0x0073f402
in __kernel_vsyscall ()
3thread
0xb41a9b90 (lwp 18682) 0x0073f402
in __kernel_vsyscall ()
2thread
0xb37a8b90 (lwp 18683) 0x0073f402
in __kernel_vsyscall ()*1
thread
0xb7fb26e0 (lwp 18675) 0x0073f402
in __kernel_vsyscall ()
(gdb) thread 2
除錯完成後，要使用detach命令，讓程式可以繼續跑起來。
(gdb) detach
detaching from program: ***, process
18675
當前呼叫的資料，在l->ci中可以查到，上一層呼叫的資料儲存在l->ci - 1中，一直到l->base_ci。
呼叫的檔名，以及行數，可以檢視：
l->ci->func->value->gc->cl->l->p->source
l->ci->func->value->gc->cl->l->p->lineinfo
用GDB除錯程式
用gdb除錯程式 gdb概述 gdb是gnu開源組織發布的乙個強大的unix下的程式除錯工具。或許，各位比較喜歡那種圖形介面方式的，像vc bcb等ide的除錯，但如果你是在unix平台下做軟體，你會發現gdb這個除錯工具有比vc bcb的圖形化偵錯程式更強大的功能。所謂 寸有所長，尺有所短 就是這...
用GDB除錯程式
七 設定顯示選項 gdb中關於顯示的選項比較多，這裡我只例舉大多數常用的選項。set print address set print address on 開啟位址輸出，當程式顯示函式資訊時，gdb會顯出函式的引數位址。系統預設為開啟的，如 gdb f 0 set quotes lq 0x34c78...
用GDB除錯程式
用gdb除錯程式 gdb概述 gdb是gnu開源組織發布的乙個強大的unix下的程式除錯工具。或許，各位比較喜歡那種圖形介面方式的，像vc bcb等ide的除錯，但如果你是在unix平台下做軟體，你會發現gdb這個除錯工具有比vc bcb的圖形化偵錯程式更強大的功能。所謂 寸有所長，尺有所短 就是這...