title: Determining the correct thread to debug in GDB
body: <p>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</p>
  
  <pre><code>(gdb) thread apply all where
  </code></pre>
  
  <p>is giving me shockingly useless information in the form:</p>
  
  <pre><code>#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
  </code></pre>
  
  <p>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).</p>
  
  <p>This is what I have so far:</p>
  
  <pre><code>(gdb) gdb
  (gdb) gdb attach &lt;processid&gt;
  (gdb) thread apply all 'XML_File_Data::XML_File_Data()'
  </code></pre>
  
  <p>and (after the breakpoint is hit)</p>
  
  <pre><code>(gdb) thread apply all where
  </code></pre>
  
  <p>Could any experienced debuggers offer me some hints on what I am doing wrong or what is normally done in this situation?</p>
  
  <p>Cheers,
  Charlie</p>
  
  <p>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.</p>