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调试核心＃文件 - 得到完整的命令导致崩溃

回答

相关问题