gdb調試多線程程序總結
來源 https://www.cnblogs.com/jingzhishen/p/4324071.html
一、多線程調試
1. 多線程調試,最重要的幾個命令:
info threads 查看當前進程的線程。
GDB會為每個線程分配一個ID, 后面操作線程的時候會用到這個ID.
前面有*的是當前調試的線程.
thread <ID> 切換調試的線程為指定ID的線程。
break file.c:100 thread all 在file.c文件第100行處為所有經過這里的線程設置斷點。
set scheduler-locking off|on|step
在使用step或者continue命令調試當前被調試線程的時候，其他線程也是同時執行的,
怎么只讓被調試程序執行呢？
通過這個命令就可以實現這個需求。
off 不鎖定任何線程，也就是所有線程都執行，這是默認值。
on 只有當前被調試程序會執行。
step 在單步的時候，除了next過一個函數的情況
(熟悉情況的人可能知道，這其實是一個設置斷點然后continue的行為)以外，
只有當前線程會執行。
thread apply ID1 ID2 command 讓一個或者多個線程執行GDB命令command
thread apply all command 讓所有被調試線程執行GDB命令command。
2. 使用示例:
線程產生通知：在產生新的線程時, gdb會給出提示信息
(gdb) r
Starting program: /root/thread
[New Thread 1073951360 (LWP 12900)]
[New Thread 1082342592 (LWP 12907)]---以下三個為新產生的線程
[New Thread 1090731072 (LWP 12908)]
[New Thread 1099119552 (LWP 12909)]
查看線程：使用info threads可以查看運行的線程。
(gdb) info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
* 1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb)
注意，行首為gdb分配的線程ID號，對線程進行切換時，使用該ID號碼。
另外，行首的星號標識了當前活動的線程
切換線程：
使用 thread THREADNUMBER 進行切換，THREADNUMBER 為上文提到的線程ID號。
下例顯示將活動線程從 1 切換至 4。
(gdb) info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
* 1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb) thread 4
[Switching to thread 4 (Thread 1099119552 (LWP 12940))]#0 0xffffe002 in ?? ()
(gdb) info threads
* 4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb)
以上即為使用gdb提供的對多線程進行調試的一些基本命令。
另外，gdb也提供對線程的斷點設置以及對指定或所有線程發布命令的命令
二、調試宏
在GDB下, 我們無法print宏定義，因為宏是預編譯的。
但是我們還是有辦法來調試宏，這個需要GCC的配合。
在GCC編譯程序的時候，加上
-ggdb3 參數，這樣，你就可以調試宏了。
另外，你可以使用下述的GDB的宏調試命令 來查看相關的宏。
info macro 查看這個宏在哪些文件里被引用了，以及宏定義是什么樣的。
macro 查看宏展開的樣子。
三、源文件
GDB時,提示找不到源文件。
需要做下面的檢查:
編譯程序員是否加上了 -g參數 以包含debug信息。
路徑是否設置正確了。
使用GDB的directory命令來設置源文件的目錄。
下面給一個調試/bin/ls的示例(ubuntu下)
$ apt-get source coreutils
$ sudo apt-get install coreutils-dbgsym
$ gdb /bin/ls
GNU gdb (GDB) 7.1-ubuntu
(gdb) list main
1192 ls.c: No such file or directory.
in ls.c
(gdb) directory ~/src/coreutils-7.4/src/
Source directories searched: /home/hchen/src/coreutils-7.4:$cdir:$cwd
(gdb) list main
1192 }
1193 }
1194
1195 int
1196 main (int argc, char **argv)
1197 {
1198 int i;
1199 struct pending *thispend;
1200 int n_files;
1201
四、條件斷點
條件斷點是語法是：
break [where] if [condition]
這種斷點真是非常管用。
尤其是在一個循環或遞歸中，或是要監視某個變量。
注意，這個設置是在GDB中的，只不過每經過那個斷點時GDB會幫你檢查一下條件是否滿足。
五、命令行參數
有時候，我們需要調試的程序需要有命令行參數, 有三種方法：
gdb命令行的 -args 參數
gdb環境中 set args命令。
gdb環境中 run 參數
六、gdb的變量
有時候，在調試程序時，我們不單單只是查看運行時的變量，
我們還可以直接設置程序中的變量，以模擬一些很難在測試中出現的情況，比較一些出錯，
或是switch的分支語句。使用set命令可以修改程序中的變量。
另外，你知道gdb中也可以有變量嗎？
就像shell一樣，gdb中的變量以$開頭，比如你想打印一個數組中的個個元素，你可以這樣：
(gdb) set $i = 0
(gdb) p a[$i++]
... #然后就一路回車下去了
當然，這里只是給一個示例，表示程序的變量和gdb的變量是可以交互的。
七、x命令
也許，你很喜歡用p命令。
所以，當你不知道變量名的時候，你可能會手足無措，因為p命令總是需要一個變量名的。
x命令是用來查看內存的，在gdb中 “help x” 你可以查看其幫助。
x/x 以十六進制輸出
x/d 以十進制輸出
x/c 以單字符輸出
x/i 反匯編 – 通常，我們會使用 x/10i $ip-20 來查看當前的匯編（$ip是指令寄存器）
x/s 以字符串輸出
八、command命令
如何自動化調試。
這里向大家介紹command命令，簡單的理解一下，其就是把一組gdb的命令打包，有點像字處理軟件的“宏”。
下面是一個示例：
(gdb) break func
Breakpoint 1 at 0x3475678: file test.c, line 12.
(gdb) command 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>print arg1
>print arg2
>print arg3
>end
(gdb)
當我們的斷點到達時，自動執行command中的三個命令，把func的三個參數值打出來。
http://www.cnblogs.com/aixingfou/archive/2011/07/28/2119875.html
http://blog.csdn.net/nancygreen/article/details/14226925
先介紹一下GDB多線程調試的基本命令。 info threads 顯示當前可調試的所有線程，每個線程會有一個GDB為其分配的ID，后面操作線程的時候會用到這個ID。 前面有*的是當前調試的線程。 thread ID 切換當前調試的線程為指定ID的線程。 break thread_test.c:123 thread all在所有線程中相應的行上設置斷點thread apply ID1 ID2 command 讓一個或者多個線程執行GDB命令command。 thread apply all command 讓所有被調試線程執行GDB命令command。 set scheduler-locking off|on|step 估計是實際使用過多線程調試的人都可以發現，在使用step或者continue命令調試當前被調試線程的時候，其他線程也是同時執行的，怎么只讓被調試 程序執行呢？通過這個命令就可以實現這個需求。off 不鎖定任何線程，也就是所有線程都執行，這是默認值。 on 只有當前被調試程序會執行。 step 在單步的時候，除了next過一個函數的情況(熟悉情況的人可能知道，這其實是一個設置斷點然后continue的行為)以外，只有當前線程會執行。
gdb對於多線程程序的調試有如下的支持：
- 線程產生通知：在產生新的線程時, gdb會給出提示信息
(gdb) r
Starting program: /root/thread
[New Thread 1073951360 (LWP 12900)]
[New Thread 1082342592 (LWP 12907)]---以下三個為新產生的線程
[New Thread 1090731072 (LWP 12908)]
[New Thread 1099119552 (LWP 12909)]
- 查看線程：使用可以查看運行的線程。info threads
(gdb) info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
* 1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb)
注意，行首的藍色文字為gdb分配的線程號，對線程進行切換時，使用該該號碼，而不是上文標出的綠色數字。
另外，行首的紅色星號標識了當前活動的線程
- 切換線程：使用 thread THREADNUMBER 進行切換，THREADNUMBER 為上文提到的線程號。下例顯示將活動線程從 1 切換至 4。
(gdb) info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
* 1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb) thread 4
[Switching to thread 4 (Thread 1099119552 (LWP 12940))]#0 0xffffe002 in ?? ()
(gdb) info threads
* 4 Thread 1099119552 (LWP 12940) 0xffffe002 in ?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in ?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in ?? ()
1 Thread 1073951360 (LWP 12931) main (argc=1, argv=0xbfffda04) at thread.c:21
(gdb)
以上即為使用gdb提供的對多線程進行調試的一些基本命令。另外，gdb也提供對線程的斷點設置以及對指定或所有線程發布命令的命令。
初次接觸gdb下多線程的調試，往往會忽視gdb中活動線程的概念。一般來講，在使用gdb調試的時候，只有一個線程為活動線程，如果希望得到其他的線程的輸出結果，必須使用thread命令切換至指定的線程，才能對該線程進行調試或觀察輸出結果。
最后介紹一下我最近遇見的一個多線程調試和解決。
基本問題是在一個Linux環境中，調試多線程程序不正常，info threads看不到多線程的信息。
我先用命令maintenance print target-stack看了一下target的裝載情況，發現target"multi-thread"沒有被裝載，用GDB對GDB進行調試，發現在 函數check_for_thread_db在調用libthread_db中的函數td_ta_new的時候，返回了TD_NOLIBTHREAD，所 以沒有裝載target"multi-thread"。
在時候我就懷疑是不是libpthread有問題，於是檢查了一下發現了問題，這個環境中的libpthread是被strip過的，我想可能 就是以為這個影響了td_ta_new對libpthread符號信息的獲取。當我換了一個沒有strip過的libpthread的時候，問題果然解決 了。
最終我的解決辦法是拷貝了一個.debug版本的libpthread到lib目錄中，問題解決了。
多線程如果dump，多為段錯誤，一般都涉及內存非法讀寫。可以這樣處理，使用下面的命令打開系統開關，讓其可以在死掉的時候生成core文件。
ulimit -c unlimited
這樣的話死掉的時候就可以在當前目錄看到core.pid(pid為進程號)的文件。接着使用gdb:
gdb ./bin ./core.pid
進去后，使用bt查看死掉時棧的情況，在使用frame命令。
還有就是里面某個線程停住，也沒死，這種情況一般就是死鎖或者涉及消息接受的超時問題(聽人說的，沒有遇到過)。遇到這種情況，可以使用：
gcore pid （調試進程的pid號）
手動生成core文件，在使用pstack(linux下好像不好使)查看堆棧的情況。如果都看不出來，就仔細查看代碼，看看是不是在if，return，break，continue這種語句操作是忘記解鎖，還有嵌套鎖的問題，都需要分析清楚了。
原文地址 http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=program&Number=692404&page=0&view=collapsed
一個 Linux 上分析死鎖的簡單方法
pstack 在 Linux 平台上的簡單介紹
pstack 是 Linux（比如 Red Hat Linux 系統、Ubuntu Linux 系統等）下一個很有用的工具，它的功能是打印輸出此進程的堆棧信息。可以輸出所有線程的調用關系棧。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
yingc@yingc:~/tmp/sisuo$ sudo gdb -q ./lock 13011
Reading symbols from ./lock...done.
Attaching to program: /home/yingc/tmp/sisuo/lock, process 13011
Reading symbols from /lib/i386-linux-gnu/libpthread.so.0...Reading symbols from /usr/lib/debug
//lib/i386-linux-gnu/libpthread-2.19.so...done.
done.
[New LWP 13015]
[New LWP 13014]
[New LWP 13013]
[New LWP 13012]
[Thread debugging
using
libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/libthread_db.so.1"
.
Loaded symbols
for
/lib/i386-linux-gnu/libpthread.so.0
Reading symbols from /lib/i386-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug
//lib/i386-linux-gnu/libc-2.19.so...done.
done.
Loaded symbols
for
/lib/i386-linux-gnu/libc.so.6
Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug
//lib/i386-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols
for
/lib/ld-linux.so.2
0xb778bc7c in __kernel_vsyscall ()
(gdb) info threads
Id Target Id Frame
5 Thread 0xb759db40 (LWP 13012)
"lock"
0xb778bc7c in __kernel_vsyscall ()
4 Thread 0xb6d9cb40 (LWP 13013)
"lock"
0xb778bc7c in __kernel_vsyscall ()
3 Thread 0xb659bb40 (LWP 13014)
"lock"
0xb778bc7c in __kernel_vsyscall ()
2 Thread 0xb5d9ab40 (LWP 13015)
"lock"
0xb778bc7c in __kernel_vsyscall ()
* 1 Thread 0xb759e700 (LWP 13011)
"lock"
0xb778bc7c in __kernel_vsyscall ()
(gdb) t 5
[Switching to
thread
5 (Thread 0xb759db40 (LWP 13012))]
#0 0xb778bc7c in __kernel_vsyscall ()
(gdb) bt
#0 0xb778bc7c in __kernel_vsyscall ()
#1 0xb775b792 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:144
#2 0xb77571e3 in _L_lock_851 () from /lib/i386-linux-gnu/libpthread.so.0
#3 0xb7757020 in __GI___pthread_mutex_lock (mutex=0x804a060 <mutex2>) at ../nptl/pthread_mutex_lock.c:79
#4 0x08048738 in func1 () at lock.cpp:18
#5 0x080487ee in thread1 (arg=0x0) at lock.cpp:43
#6 0xb7754f16 in start_thread (arg=0xb759db40) at pthread_create.c:309
#7 0xb768b9fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb)
|
pstack在我機子上貌似不好使用
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
yingc@yingc:~/tmp/sisuo$ pstack 13011
Could not attach to target 13011: Operation not permitted.
detach: No such process
yingc@yingc:~/tmp/sisuo$ sudo pstack 13011
[sudo] password
for
yingc:
13011: ./lock
(No symbols found in )
(No symbols found in /lib/i386-linux-gnu/libc.so.6)
(No symbols found in /lib/ld-linux.so.2)
0xb778bc7c: _fini + 0x2caec (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
0x09279010: _fini + 0x123054c (b759db40, 1, b778bc6c, 15a6a100, e608f43e, 0) + ffffffe0
|