Déboguer du code multithread avec gdb mais pas d'accès aux variables privées?

Question

Salut les gars. Mon programme utilise OpenMP à quelques parties pour faire du multithreading. Cela fonctionne pour la plupart, mais de temps en temps stalles et se trouve juste là. Donc, je le lance dans le débogueur, et je trouve la zone où il se bloque. Ensuite, j'essaie d'examiner les variables actuelles, et je reçois ceci:

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

Je ne sais pas pourquoi c'est. Je peux imprimer cela quand il n'y a qu'un seul thread. J'ai privatisé cette variable, et j'imagine que le programme ne sait pas de quel thread je parle quand je lui demande d'imprimer quelque chose (même si ce http://cc.jct.ac.il/cc-res/online-doc/gdb/gdb_26.html#SEC26 dit qu'il y aura toujours un fil courant ..?). Donc, si je choisis un seul thread, je reçois les mêmes choses:

(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. 

Je suis en fait un peu confus au sujet de cette partie. Ma machine n'a que deux processeurs. Comment peut-il y avoir 3 threads? Je vois que les deux nombres hexadécimaux juste avant __semwait_signal() sont les mêmes, mais je ne sais pas pourquoi ils sont séparés. Comment puis-je regarder les variables pour un seul thread?

Merci!

Answer 1

Ma machine ne dispose que de deux processeurs. Comment peut-il y avoir 3 threads?

Le nombre de fils n'a rien à voir avec le nombre de cores (CPU réel ou virtuel (AKA hyperthreading). Vous pouvez (presque) autant de sujets que vous le souhaitez (limité seulement par le système d'exploitation). Le planificateur de l'OS est responsable de distribuer le temps CPU aux threads de manière équitable - et de réveiller les threads en sommeil, s'il y a quelque chose de nouveau pour eux (blocage des E/S terminées, nouvelles données sur la socket, etc.)

En ce qui concerne votre "symbole non trouvé" -problème: Y a-t-il des informations de débogage complètes ou limitées? (Quelle option -g avez-vous utilisée?) Et quelle version de gdb? Il peut arriver que les variables ou le pointeur puissent être "optimisés "et gardé dans un re Gister. Alors gdb n'est pas capable d'afficher la valeur de la variable. Cependant, toutes les versions de gdb que j'ai utilisées connaissent encore le symbole, mais ne peuvent pas donner la valeur (il affiche un message "valeur optimisée").

Answer 2

Je l'ai remarqué à certains moments aussi. Mais je l'ai typiquement fait en faisant print *this pour juste vider le contenu de l'objet actuel (en supposant que velPtr est dans l'objet courant).

J'aimerais aussi apprendre la réponse finale, mais cette solution de contournement peut vous aider dans le même temps.

Answer 3

Si vous ne l'avez pas encore résolu ce ...

J'ai eu le même problème et résolu à l'aide des -gstabs + (au lieu de simplement -G) lors de la compilation avec g ++.

Cependant, je reçois toujours 'No symbol' var "dans le contexte actuel" lorsque j'essaie d'imprimer des variables partagées. Pour une raison quelconque, il n'y a pas de problème d'impression variables partagées qui sont aussi des variables globales (??)