Отладка многопоточного кода с помощью GDB, но нет доступа к закрытым переменным? - PullRequest
1 голос
/ 13 августа 2010

Привет, ребята.Моя программа использует OpenMP в нескольких частях для многопоточности.Это работает по большей части, но иногда останавливается и просто сидит там.Поэтому я запускаю его в отладчике и нахожу область, в которой он останавливается.Затем я пытаюсь изучить текущие переменные, и я получаю это:

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

Я не уверен, почему это так.Я могу напечатать это, когда это только однопоточный.Я приватизировал эту переменную, и я думаю, что программа не будет знать, на какой поток я ссылаюсь, когда я прошу ее напечатать что-нибудь (даже если это http://cc.jct.ac.il/cc-res/online-doc/gdb/gdb_26.html#SEC26 говорит, что текущий поток всегда будет ..?).Так что, если я выберу один поток, я получу тот же материал:

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

Я на самом деле немного запутался в этой части.У моей машины только два процессора.Как может быть 3 темы?Я вижу, что два шестнадцатеричных числа перед __semwait_signal () одинаковы, но я не знаю, почему они разделены.Как я могу посмотреть на переменные для одного потока?

Спасибо!

Ответы [ 3 ]

3 голосов
/ 22 декабря 2011

В случае, если вы еще не решили это ...

У меня была та же проблема, и я решил ее, используя опцию -gstabs + (вместо просто -g) при компиляции с g ++.

Тем не менее, я все еще получаю «Без символа« var »в текущем контексте» при попытке печати общих переменных. По какой-то причине нет проблем с печатью общих переменных, которые также являются глобальными переменными (??)

2 голосов
/ 13 августа 2010

У моей машины только два процессора. Как может быть 3 темы?

Количество потоков не имеет ничего общего с количеством (реальных или виртуальных (гиперпоточность) ядер ЦП). Вы можете иметь (почти) столько потоков, сколько пожелаете (ограничено только операционной системой). Планировщик ОС отвечает за справедливое распределение процессорного времени между потоками и пробуждает спящие потоки, если для них есть что-то новое (блокировка ввода-вывода завершена, новые данные в сокете и т. *

Относительно вашей проблемы "символ не найден": доступна ли полная или только ограниченная информация отладки? (Какой вариант -g вы использовали?) И какую версию GDB? Может случиться, что переменные или указатель могут быть «оптимизированы» и сохранены в регистре. Тогда GDB не может показать значение переменной. Однако все версии GDB, которые я тогда использовал, все еще знают, что символ существует, но не могут дать значение (оно показывает сообщение «значение оптимизировано»).

0 голосов
/ 14 августа 2010

Я тоже это иногда замечал. Но, как правило, я обошел это, выполнив print *this, чтобы просто вывести содержимое текущего объекта (при условии, что velPtr находится в текущем объекте).

Я бы тоже хотел узнать окончательный ответ, но этот обходной путь может помочь вам в это время.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...