确定在GDB中调试的正确线程 [英] Determining the correct thread to debug in GDB

问题描述

我遇到了一些使用GDB调试多线程进程的问题。我有一个多线程进程，分裂成几个（8或9）不同的线程，我试图确定当调用一个名为XML_File_Data的类的构造函数时，变量的内容是什么。但是，我遇到了一个问题，在将正确的函数断点应用于所有线程之后，显然线程的某个断点正在被击中（程序暂时停止执行）后，我无法确定哪个线程打到了断点。命令

 （gdb）线程全部应用
  

给了我惊人的无用信息：

 ＃0 0x004ab410 in __kernel_vsyscall（）
＃1 0x05268996 in nanosleep（）from /lib/libc.so.6 
＃2 0x052a215c in usleep（）from /lib/libc.so.6 
＃3 0x082ee313在frame_clock_frame_end（clock = 0xb4bfd2f8）
在frame_clock.c：143 
＃4 0x003a349a in ?? （）
＃5 0x00b5cfde in thread_proxy（）
 from /cets_development_libraries/install/lib/libboost_thread-gcc41-mt-1_38.so.1.38.0 
＃6 0x02c1f5ab in start_thread（）from /lib/libpthread.so.0 
＃7从/lib/libc.so.6克隆（）0x052a8cfe 
  

在9个进程中，7个左右给出了几乎完全一样的输出结果，而关于最后2个的信息并没有多大帮助（远离调用堆栈的函数具有可识别的名称，但任何最近的＃0-＃4功能是不可识别的）。

这就是我到目前为止：

 （gdb）gdb 
（gdb）gdb attach< processid> 
（gdb）线程全部应用'XML_File_Data :: XML_File_Data（）'
  

和（after

 （gdb）线程全部应用
  

任何有经验的调试者都会提供一些提示，说明我在做什么错误或在这种情况下通常会做什么？

干杯，
查理

编辑：幸运的是，我能够发现这个问题的原因是经过优化的代码正在运行调试器除了不在可执行文件的目录中运行调试器外。您可以使用线程命令或线程 信息线程在断点命中后找出当前线程号

$ g $ gb线程
当前线程数线程为1（线程0xb790d6c0（LWP 2519））]
（gdb）

（gdb）信息线程
17 __kernel_vsyscall（）中的线程0xb789cb90（LWP 2536）0xb7fc6402 $ b 16线程0xb769bb90（LWP 2537）0xb7fc6402 in __kernel_vsyscall（）
15线程0xb749ab90（LWP 2543）0xb7fc6402 in __kernel_vsyscall（）
14线程0xb7282b90（LWP 2544）0xb7fc6402 in __kernel_vsyscall（）
（）
12线程0xb5627b90（LWP 2707）0xb7fc6402 in __kernel_vsyscall（）
12线程0xb5626b90（LWP 2708）0xb7fc6402 in __kernel_vsyscall（）
11线程0xb5425b90（LWP 2709）0xb7fc6402 in __kernel_vsyscall 0xb5161b90（LWP 2713）__kernel_vsyscall（）中的0xb7fc6402
9线程0xb4ef9在__kernel_vsyscall（）
8中线程0xb4af7b90（LWP 2717）0xb7fc6402在__kernel_vsyscall（）
中线程0xb46ffb90（LWP 2718）0xb7fc6402
6线程0xb44feb90（LWP 2715）0xb7fc6402 LWP 2726）__kernel_vsyscall（）中的0xb7fc6402
线程0xb42fdb90（LWP 2847）0xb7fc6402 in __kernel_vsyscall（）
4线程0xb40fcb90（LWP 2848）0xb7fc6402在__kernel_vsyscall（）
3线程0xb3efbb90（LWP 2849） ）__kernel_vsyscall（）中的0xb7fc6402
2线程0xb3cfab90（LWP 2850）0xb7fc6402 in __kernel_vsyscall（）
* 1线程0xb790d6c0（LWP 2519）__kernel_vsyscall（）中的0xb7fc6402
（gdb）

gdb线程号左边的星号*表示当前线程。请参阅此处。

I've run into some problems debugging a multi-threaded process using GDB. I have a multi-threaded process that splinters off into several (8 or 9) different threads, and I am trying to determine what the contents of variables are when the constructor for a class called XML_File_Data is called. However, I've run into a problem where, after I apply the correct function breakpoint to all threads and it's apparent one of the thread's break point is getting hit (the program temporarily halts execution), I'm not able to determine which thread hit the breakpoint. The command

(gdb) thread apply all where

is giving me shockingly useless information in the form:

#0  0x004ab410 in __kernel_vsyscall ()
#1  0x05268996 in nanosleep () from /lib/libc.so.6
#2  0x052a215c in usleep () from /lib/libc.so.6
#3  0x082ee313 in frame_clock_frame_end (clock=0xb4bfd2f8)
    at frame_clock.c:143
#4  0x003a349a in ?? ()
#5  0x00b5cfde in thread_proxy ()
   from /cets_development_libraries/install/lib/libboost_thread-gcc41-mt-1_38.so.1.38.0
#6  0x02c1f5ab in start_thread () from /lib/libpthread.so.0
#7  0x052a8cfe in clone () from /lib/libc.so.6

Of the 9 processes, 7 or so are giving me almost exactly that output, and the information about the last 2 isn't really much more helpful (functions far down the call stack have recognizable names, but any recent #0-#4 functions aren't recognizable).

This is what I have so far:

(gdb) gdb
(gdb) gdb attach <processid>
(gdb) thread apply all 'XML_File_Data::XML_File_Data()'

and (after the breakpoint is hit)

(gdb) thread apply all where

Could any experienced debuggers offer me some hints on what I am doing wrong or what is normally done in this situation?

Cheers, Charlie

EDIT: Fortunately, I was able to find out that the cause of the ??'s was optimized code being run through the debugger, in addition to not running the debugger in the directory of the executable file. Still not much success with the debugging though.

解决方案

You can use command thread or info threads to find out the current thread number after breakpoint hit

(gdb) thread
[Current thread is 1 (Thread 0xb790d6c0 (LWP 2519))]
(gdb)

(gdb) info threads
  17 Thread 0xb789cb90 (LWP 2536)  0xb7fc6402 in __kernel_vsyscall ()
  16 Thread 0xb769bb90 (LWP 2537)  0xb7fc6402 in __kernel_vsyscall ()
  15 Thread 0xb749ab90 (LWP 2543)  0xb7fc6402 in __kernel_vsyscall ()
  14 Thread 0xb7282b90 (LWP 2544)  0xb7fc6402 in __kernel_vsyscall ()
  13 Thread 0xb5827b90 (LWP 2707)  0xb7fc6402 in __kernel_vsyscall ()
  12 Thread 0xb5626b90 (LWP 2708)  0xb7fc6402 in __kernel_vsyscall ()
  11 Thread 0xb5425b90 (LWP 2709)  0xb7fc6402 in __kernel_vsyscall ()
  10 Thread 0xb5161b90 (LWP 2713)  0xb7fc6402 in __kernel_vsyscall ()
  9 Thread 0xb4ef9b90 (LWP 2715)  0xb7fc6402 in __kernel_vsyscall ()
  8 Thread 0xb4af7b90 (LWP 2717)  0xb7fc6402 in __kernel_vsyscall ()
  7 Thread 0xb46ffb90 (LWP 2718)  0xb7fc6402 in __kernel_vsyscall ()
  6 Thread 0xb44feb90 (LWP 2726)  0xb7fc6402 in __kernel_vsyscall ()
  5 Thread 0xb42fdb90 (LWP 2847)  0xb7fc6402 in __kernel_vsyscall ()
  4 Thread 0xb40fcb90 (LWP 2848)  0xb7fc6402 in __kernel_vsyscall ()
  3 Thread 0xb3efbb90 (LWP 2849)  0xb7fc6402 in __kernel_vsyscall ()
  2 Thread 0xb3cfab90 (LWP 2850)  0xb7fc6402 in __kernel_vsyscall ()
* 1 Thread 0xb790d6c0 (LWP 2519)  0xb7fc6402 in __kernel_vsyscall ()
(gdb)

An asterisk `*' to the left of the gdb thread number indicates the current thread. See here.

这篇关于确定在GDB中调试的正确线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！