GDB не может показать стек и показывает «# 1 0x0000000000000000 in ?? ()» - PullRequest
Новая
       28

GDB не может показать стек и показывает «# 1 0x0000000000000000 in ?? ()»

4 голосов
/ 28 июля 2011

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

  1. запустить программу
  2. ожидание тупика
  3. отправить сигнал прерывания для создания дампа ядра
  4. скопировать дамп обратно на мой локальный компьютер
  5. используйте gdb для его отладки

У меня нет gdb на удаленной машине, и я не могу ничего установить на него. Проблема в том, что когда я отлаживаю дамп ядра (полученный из заблокированного или нормально работающего процесса на удаленном компьютере), обратная трассировка большинства потоков показывает только: 

(gdb) bt
#0  pthread_cond_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x0000000000000000 in ?? ()

Я использую статически связанный двоичный файл, который компилируется с опциями "-g -O1". Когда я прерываю процесс того же двоичного файла на моей локальной машине, GDB может извлечь весь стек из дампа памяти, и такой проблемы нет (однако я не могу воспроизвести тупик). Мой удаленный компьютер - SLES, а мой локальный компьютер - Ubuntu.

Есть идеи?

Edit:

Нашел кого-то еще с той же проблемой, но без решения: http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 (Я не использую Google Coredumper, но кажется, что Google Coredumper не удается с той же ошибкой, это предполагает, что, возможно, проблема с SLES 11)

Ответы [ 2 ]

3 голосов
/ 28 июля 2011

Обратите внимание, что вы также можете использовать gcore для создания файла ядра без прерывания.Вы пытались запустить pstack на удаленном хосте (при условии, что он установлен), чтобы посмотреть, сможете ли вы получить обратную трассировку таким образом?

В противном случае, если общие объекты, используемые вашим приложением, отличаются на вашем локальном хосте и удаленном хостеGDB не сможет правильно сопоставить смещения памяти, и обратная трассировка, вероятно, запутается.Если вам удастся скопировать все соответствующие файлы .so с удаленного хоста в какое-либо место локально, я полагаю, что вы можете указать gdb читать из них вместо обычно установленных версий.

РЕДАКТИРОВАТЬ: попробуйте запустить pstackна вашей сборочной машине и посмотрите, сможет ли она собрать стек.

1 голос
/ 29 июля 2011

Каков возраст вашего glibc? Возможно, вам не хватает этого: 

commit ad2be8527ac0f19f129fc4519d823cbe48239c78
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sun Apr 13 08:36:19 2003 +0000

    Update.

        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Add unwind info.
        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: Likewise.
        * sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.
...