Дамп ядра многопоточного приложения показывает только один поток

Question

У меня есть тестовое приложение на c ++, которое запускает несколько потоков в своем main(), а затем спит в main() навсегда.

Один из потоков делает что-то, что вызывает segfault и генерируется coredumpulimit -c unlimited был установлен ранее).

Я открываю ядро ​​с помощью gdb и вижу с помощью thread apply all bt или info threads, что у меня только один поток (запущенный в main()), которыйневозможно, потому что по крайней мере поток main() также должен работать.

Вопрос в том, как возможно, что остальные потоки отсутствуют, и что может вызвать это?

Обратный след этого одинокого потока кажется нормальным, в нем нет ничего странного.

Операционная система - Red Hat Enterprise 5.3, gdb-6.8.

Answer 1

Причина, по которой вы видите только один поток, заключается в том, что GDB не может различать потоки «по себе», он опирается на внешнюю библиотеку libthread_db , предоставляемую библиотекой потоков.

Эта библиотека должна быть включена в начале сеанса отладки, чтобы отслеживать действия потоков (рождение, смерть, ...) и передавать всю информацию, связанную с потоками, в GDB во время выполнения.

Вы должны уметь читать

[Thread debugging using libthread_db enabled]

при попытке отладки любого файла, скомпилированного с -lpthread, но GDB даже не пытается включить libthread_db при отладке дампа ядра.

Answer 2

Оказалось, что это ошибка ядра по умолчанию в Red Hat Enterprise 5.3, исправленная в более поздней версии Red Hat (5.4) - kernel-2.6.18-164.el5

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/5.4_Technical_Notes/index.html

1.110.1.RHSA-2009: 1193: важные обновления безопасности и исправления ошибок в 32-разрядных системах, дампы ядра для некоторых многопоточных приложений не включали всю информацию о потоках.(БЗ № 505322)

https://bugzilla.redhat.com/show_bug.cgi?id=505322

Answer 3

Попробуйте запустить приложение под Valgrind. Мэйби, это поможет выяснить причину сбоя.

Answer 4

Если у вас нет sighandler для SIGEGV с alt stack, что является особым случаем, просто используйте strace.

strace -f myprogram

(мужчина)

(нам нужен флаг -f, потому что потоки всегда являются глобальной областью действия в Linux. Например, ~ procs, которые работают в одной и той же памяти)

Вот пример выходных данных, показывающий поток, завершившийся до сбоя. Я выделил интересную часть ...

Клон (

Процесс 28757 прилагается

child_stack = 0x7fc1fc319ff0, флаги = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID, parent_tidptr = 0x7fc1fc31a9e0, 0x7fc1fc31a710 = TLS, child_tidptr = 0x7fc1fc31a9e0) = 28757

[pid 28756] rt_sigprocmask (SIG_BLOCK, [CHLD],

[pid 28757] set_robust_list (0x7fc1fc31a9f0, 0x18

[pid 28756] <... rt_sigprocmask возобновлен> [], 8) = 0

[pid 28757] <... set_robust_list возобновлен>) = 0

[pid 28756] rt_sigaction (SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

[pid 28757] madvise (0x7fc1fb91a000, 10465280, MADV_DONTNEED

[pid 28756] rt_sigprocmask (SIG_SETMASK, [],

[pid 28757] <... madvise возобновлен>) = 0

[pid 28756] <... rt_sigprocmask возобновлен> NULL, 8) = 0

[pid 28757] _exit (0) =?

Процесс 28757 отсоединен

nanosleep ({1, 0}, 0x7fffce29c4b0) = 0

rt_sigprocmask (SIG_UNBLOCK, [ABRT], NULL, 8) = 0

tgkill (28756, 28756, SIGABRT) = 0 --- SIGABRT (Прервано) @ 0 (0) ---

+++ убит SIGABRT (ядро сброшено) +++

Прервано (ядро сброшено)

Теперь выполните grep в выходных данных и убедитесь, что число подключенных и отключенных. Если у вас действительно есть живые потоки на выходе (сбой), я бы создал запись bugzilla (первый поиск bugzilla ofc).

Answer 5

Вы действительно уверены, что это невозможно? Возможно, проблема как раз связана с тем, что основной поток вышел без ожидания других потоков.