gdb調試核心＃文件 - 得到完整的命令導致崩潰

我有一些複雜的問題（通過複雜的我的意思是我找不到一個解決方案，在幾個小時的研究），問題是：gdb調試核心＃文件 - 得到完整的命令導致崩潰

我提交了大量腳本來運行（在SGE集羣上），其中一些腳本生成了核心。＃文件（核心轉儲文件）。我想我可以打開這些文件使用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 ..../graphmap core」的程序加載gdb，但我仍然得到了錯誤命令的開頭，並且沒有其他任何東西。

任何幫助建議將不勝感激。

更新：正如用戶@ 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*)()

它並沒有告訴我很多，所以我繼續尋找一個「主線」。我切換到每個線程，一個一個地執行「信息堆棧」。包含相關的時候，唯一線程的線程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 /斌/ Linux的X64/graphmap對準 --overlappe」產生

核心

任何幫助從這裏會很有意思ciated。

最後更新，問題就迎刃而解了：我跟着@ ks1322建議，前往該stack overflow thread，然後我重複了在第一次的答案被描述並能得到的參數。我有限的使用gdb的知識所理解的東西的簡短概述：首先，您應該檢查哪些線程正在運行任務，您可以使用「info threads」來執行此操作，然後您需要檢查哪個線程具有「main 「在它的堆棧中，我通過使用」thread＃「逐個切換線程並使用」info stack「打印堆棧直到找到主要的線程，在我的情況下，它在」 info stack「＃9 0x00000000005087fe in main（）」然後根據鏈接線程中的指令，我執行了「set backtrace past-main」，然後「bt」，然後將幀更改爲包含「in _start（）」的幀命令「frame＃」，幾乎完成了，現在我運行命令「x/8gx $ rsp + 8」，顯示了幾行，每行有2個收件人。在我的情況下，第二行看起來像這樣「0x7ffe38f872d8：0x00007ffe38f88c35 0x00007ffe38f88c73」現在如果一切正常，這個地址可以包含導致粉碎命令的參數之一，你可以用「x/s」命令檢查它像這樣：「x/s 0x00007ffe38f88c35」並打印參數。重要提示：我有很多參數，所以我需要轉到後面的地址，而這些地址沒有在「x/8gx $ rsp + 8」命令中顯示，我注意到地址是按常量值遞增的（3進制）我手動保存在一個計算器中，在地址中添加「3」並用x/s檢查地址，直到我得到我想要的參數）

非常混亂的解決方案，我希望有人能找到更簡單的解決方案，但那就是我能找到。

非常感謝@ks1322誰清理了我的東西，並引導我到解決方案。

來源

2017-01-26 artembus

可以使用匹配的二進制文件（生成核心轉儲的二進制文件）加載核心轉儲，並在main函數所在的幀中打印argv值。

事情是這樣的：

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）。

來源

2017-01-26 17:22:22 ks1322

感謝您的答案，我試着加載匹配的二進制文件。但我不知道如何去堆棧這個地方你建議。我不知道是否相關，但當我運行「信息堆棧」我得到這樣的東西：「＃0 0x00000000004a554b在GraphMap :: ProcessKmerCacheFri。 ... ＃1 0x00000000004a59ac在GraphMap :: GraphMa ... ＃2 0x00000000004c4d0e在GraphMap :: ProcessR .... ＃3 0x00000000004adf43在GraphMap ::參考程序... ＃4 0x00002b292e7f401e在gomp_thr ... ＃5 0x00000031d0807aa1 in start_thr ... ＃6 0x00000031d00e8aad in clone（）from /lib64/libc.so.6「我已經用點替換了長條線 – artembus

看起來像是在某個線程中崩潰，而不是'main'。你應該找到'main'線程並切換到它。看看'thread apply all bt'的輸出，然後在'main'函數中找到那個線程。 – ks1322

對不起，希望你仍然可以幫我解決這個問題。我正在更新原始文章以包含您給我的指示和輸出，但不幸的是我的問題仍未解決。無論如何，感謝您的幫助。 – artembus

gdb調試核心＃文件 - 得到完整的命令導致崩潰

回答

相關問題