Я столкнулся с некоторыми проблемами при отладке многопоточного процесса с использованием GDB. У меня есть многопоточный процесс, который разделяется на несколько (8 или 9) разных потоков, и я пытаюсь определить, каково содержимое переменных, когда вызывается конструктор для класса с именем XML_File_Data. Однако я столкнулся с проблемой, когда после применения правильной точки останова функции ко всем потокам, и становится очевидно, что одна из точек останова потока получает удар (программа временно останавливает выполнение), я не могу определить, какой поток достичь точки останова Команда
(gdb) thread apply all where
дает мне шокирующе бесполезную информацию в форме:
#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
Из 9 процессов 7 или около того дают мне почти точно такой вывод, и информация о последних 2 не очень полезна (функции, расположенные далеко внизу стека вызовов, имеют распознаваемые имена, но все последние # 4 функции не распознаются).
Это то, что я имею до сих пор:
(gdb) gdb
(gdb) gdb attach <processid>
(gdb) thread apply all 'XML_File_Data::XML_File_Data()'
и (после достижения точки останова)
(gdb) thread apply all where
Могут ли опытные отладчики подсказать мне, что я делаю неправильно или что обычно делают в этой ситуации?
Ура,
Charlie
РЕДАКТИРОВАТЬ: К счастью, я смог выяснить, что причиной оптимизированного кода было выполнение через отладчик, в дополнение к тому, что он не запускался в каталоге исполняемого файла. Тем не менее, с отладкой успехов не так много.