Debugging multithreaded code with gdb but no access to private variables?

Question

Hey guys. My program uses OpenMP at a few parts to do multithreading. It works for the most part, but occasionally stalls and just sits there. So I run it in the debugger, and I find the area it is stalling at. Then I try to examine the current variables, and I get this:

169      if(0<=myPtr[3] && myPtr[3]<=1){//Reassign the velocities.
(gdb) print myPtr[3]
No symbol "myPtr" in current context.

I'm not sure why this is. I can print that when it is only single threaded. I privatized that variable, and I imagine the program wouldn't know which thread I'm referring to when I ask it to print something (even though this http://cc.jct.ac.il/cc-res/online-doc/gdb/gdb_26.html#SEC26 says that there will always be a current thread..?). So, if I choose a single thread, I get the same stuff:

(gdb) info threads
  3 process 32970 thread 0x4203  0x90f9846e in __semwait_signal ()
  2 process 32970 thread 0x3007  0x90f9846e in __semwait_signal ()
* 1 process 32970 local thread 0x2e03  mover3dsurfaces (.omp_data_i=0xbffff030) at mover3dsurfaces.cpp:174
(gdb) thread 1
[Switching to thread 1 (process 32970 local thread 0x2e03)]
mover3dsurfaces (.omp_data_i=0xbffff030) at mover3dsurfaces.cpp:174
174       partList.velocity(i,3) = velPtr[2];
(gdb) print velPtr[1]
No symbol "velPtr" in current context.

I'm actually a little confused about this part. My machine only has two processors. How can there be 3 threads? I see that the two hex numbers right before __semwait_signal() are the same, but I don't know why they're split up. How can I look at the variables for a single thread?

Thanks!

Answer 1

My machine only has two processors. How can there be 3 threads?

The number of threads has nothing to do with the number of (real or virtual (AKA hyperthreading) CPU cores. You can have (almost) as many threads as you wish (only limited by operating system). The scheduler of the OS is responsible to distribute CPU time to the threads in a fair way - and to wake up sleeping threads, if there is something new for them (blocking I/O finished, new data on socket etc.).

Regarding your "symbol not found"-problem: Is there full or only limited debug info available? (What -g option did you use?) And which gdb version? It can happen that variables or pointer can be "optimized out" and kept in a register. Then gdb is not able to show the value of the variable. However, all gdb versions I used then still know the symbol exist, but cannot give the value (it shows a message "value optimized out").

Answer 2

I've noticed this at times too. But I've typically got around it by doing a print *this to just dump the contents of the current object (assuming velPtr is in the current object).

I'd like to learn the final answer too, but this workaround may help you in the mean time.