gdb отладка ядра. # File - получение полной команды, вызвавшей сбой

Question

У меня есть сложная проблема (сложным я имею в виду, что не удалось найти решение в течение нескольких часов после исследования), и проблема в том, что проблема:

Я отправил большое количество сценариев для запуска (в кластере SGE), некоторые из этих сценариев сгенерировали ядро. # Files (core dump files). Я полагал, что я мог бы открыть эти файлы с помощью GDB, теперь, когда я просто открыть ядро ​​# файл я вижу это:. (последние несколько строк вывода GDB)

Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'. 
Program terminated with signal 11, Segmentation fault. 
#0 0x00000000004a554b in ??() 
"/4thExp/core.82912" is a core file. 
Please specify an executable to debug. 

Теперь мой вопрос - мне нужно найдите аргументы в программе, вызвавшие крах. Вышеупомянутый результат показывает только начало команды, вызвавшей сбой: «Ядро было создано командой«/groups/nshomron/artemd/tools/graphmap/bin/Linux-x64/graphmap align --overlappe ».»

Если бы я мог видеть остальную часть команды, я бы решил свою проблему, но после нескольких часов поиска в Интернете и проверки руководства gdb я не мог найти ничего полезного. Я попытался загрузить gdb с программой, которая вызвала сбой «gdb ..../graphmap core. #», Но все же я получил только начало неисправной команды и ничего не мог получить.

Любое предложение помощи было бы очень оценено.

Обновление: Как предложил пользователь @ ks1322 - я внимательно посмотрел на потоки. Сначала я выполнил «Информация темы» и получил результат:

(gdb) info threads 
    24 Thread 0x2b29409bd700 (LWP 82927) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    23 Thread 0x2b29401b9700 (LWP 82923) 0x00000031d00f820e in __lll_lock_wait_private() from /lib64/libc.so.6 
* 22 Thread 0x2b29403ba700 (LWP 82924) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    21 Thread 0x2b29413c2700 (LWP 82932) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    20 Thread 0x2b293fbb6700 (LWP 82920) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    19 Thread 0x2b293fdb7700 (LWP 82921) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    18 Thread 0x2b2940bbe700 (LWP 82928) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    17 Thread 0x2b293f3b2700 (LWP 82916) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    16 Thread 0x2b29411c1700 (LWP 82931) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    15 Thread 0x2b2940dbf700 (LWP 82929) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    14 Thread 0x2b29419c5700 (LWP 82935) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    13 Thread 0x2b293efb0700 (LWP 82914) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    12 Thread 0x2b293f7b4700 (LWP 82918) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    11 Thread 0x2b29407bc700 (LWP 82926) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    10 Thread 0x2b293f9b5700 (LWP 82919) 0x00000031d00f820e in __lll_lock_wait_private() from /lib64/libc.so.6 
    9 Thread 0x2b29415c3700 (LWP 82933) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    8 Thread 0x2b29405bb700 (LWP 82925) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    7 Thread 0x2b292ea08be0 (LWP 82912) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    6 Thread 0x2b293ffb8700 (LWP 82922) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    5 Thread 0x2b293edaf700 (LWP 82913) 0x00000031d0045063 in vfprintf() from /lib64/libc.so.6 
    4 Thread 0x2b2940fc0700 (LWP 82930) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    3 Thread 0x2b293f1b1700 (LWP 82915) 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
    2 Thread 0x2b29417c4700 (LWP 82934) 0x0000000000412bd6 in obtainAlignment(unsigned char const*, unsigned char const*, int, unsigned char const*, unsigned char const*, int, int, int, unsigned char**, int*)() 
    1 Thread 0x2b293f5b3700 (LWP 82917) 0x00000000004a554b in GraphMap::ProcessKmerCacheFriendly_(signed char*, long, ScoreRegistry*, MappingData*, Index*, SingleSequence const*, ProgramParameters const*)() 

Он не говорил мне, очень много, поэтому я продолжал искать «основной поток». Я переключился на каждый поток, один за другим и выполнил «info stack». Единственная нить, содержащий что-то соответствующее был поток 7. выход Информация стека:

(gdb) thread 7 
[Switching to thread 7 (Thread 0x2b292ea08be0 (LWP 82912))]#0 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
(gdb) info stack 
#0 0x00000031d00ac6aa in times() from /lib64/libc.so.6 
#1 0x00000031d009bcba in clock() from /lib64/libc.so.6 
#2 0x00000000004ccaed in GraphMap::RegionSelectionNoCopy_(long, MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*)() 
#3 0x00000000004c3544 in GraphMap::ProcessRead(MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*, EValueParams const*)() 
#4 0x00000000004adf43 in GraphMap::ProcessSequenceFileInParallel() 
#5 0x00002b292e7f096f in GOMP_parallel() from /share/apps/gcc/gcc530/lib64/libgomp.so.1 
#6 0x00000000004b0b08 in GraphMap::ProcessSequenceFileInParallel(ProgramParameters*, SequenceFile*, long*, _IO_FILE*, long*, long*)() 
#7 0x00000000004b1796 in GraphMap::ProcessReadsFromSingleFile(ProgramParameters&, _IO_FILE*)() 
#8 0x00000000004b281e in GraphMap::Run(ProgramParameters&)() 
#9 0x00000000005087fe in main() 

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

ядро ​​было генерируемой `/ инструментов/graphmap/bin/Linux-x64/graphmap выравнивать --overlappe»

Любая помощь от здесь было бы очень весело лем, связанных.

Final Update, проблема решена: Я последовал совету @ ks1322 и пошел к этому stack overflow thread, а потом я повторил то, что было описано в первом ответе, и был в состоянии получить аргументы.

(краткий обзор того, что я понял с моим ограниченным знанием о работе с gdb: сначала вы должны проверить, какие потоки выполняли задачу, вы можете сделать это с помощью «информационных потоков», тогда вам нужно проверить, какой поток имеет «основной» «В этом стеке я сделал это, переключив потоки один за другим с помощью« thread # »и распечатав стек с« info stack », пока не нашел основной поток в нем. В моем случае это было показано так: info stack "# 9 0x00000000005087fe в main()". Затем в соответствии с инструкциями связанного потока я выполнил «set backtrace past-main», затем «bt», а затем изменил фрейм на фрейм, содержащий «in_start()», команда «frame #». Почти все, теперь я выполнил команду «x/8gx $ rsp + 8», в которой было показано всего четыре строки с двумя адресатами в каждой строке.В моем случае вторая строка выглядела так: «0x7ffe38f872d8: 0x00007ffe38f88c35 0x00007ffe38f88c73» , и теперь, если все было правильно, этот адрес может содержать один из аргументов команды, вызвавшей раздачу, вы можете проверить ее с помощью команды «x/s» например: «x/s 0x00007ffe38f88c35», и он печатает аргумент. Важное замечание: у меня было много аргументов, поэтому мне нужно было перейти к более поздним адресатам, которые не отображались в команде «x/8gx $ rsp + 8», я заметил, что адреса увеличиваются на постоянное значение (в шестнадцатеричном виде), поэтому Я держал вручную в калькуляторе, добавляя «3» к адресу и проверяя адрес с помощью x/s, пока не дошел до моего желаемого аргумента)

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

Большое спасибо @ks1322, которые прояснили для меня все и направили меня к решению.

Answer 1

Вы можете загрузить основной дамп с соответствующим двоичным кодом (тот, для которого был создан основной дамп) и напечатать argv значения в кадре, где находится функция main.

Что-то вроде этого:

gdb /tools/graphmap/bin/Linux-x64/graphmap /4thExp/core.82912 

Затем поднимитесь в трассировки стека в начальный кадр, где int main(int argc, char *argv[]) проживает. Теперь вы можете напечатать количество аргументов и их значений из приглашения gdb.

Обновление:
Похоже, что ваш двоичный файл многопоточен, и авария произошла в некоторой вспомогательной нити. Поэтому вы должны найти поток main и переключиться на него. Вот пример того, как сделать это для Firefox с большим количеством нитей:

(gdb) t a a bt -1 

Thread 59 (Thread 0x7f691deff700 (LWP 25924)): 
#12 0x00007f69dce93f6f in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 
.......... 
.......... 
many threads are listed here 
.......... 
.......... 
Thread 1 (Thread 0x7f69de01a740 (LWP 4143)): 
#17 0x000056374cb38817 in main() 
(gdb) t 1 
[Switching to thread 1 (Thread 0x7f69de01a740 (LWP 4143))] 
#0 0x00007f69dce8800d in poll() at ../sysdeps/unix/syscall-template.S:84 
84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 

Теперь GDB переключается на main (Тема 1).