core.# 文件的 gdb 调试 - 获取导致崩溃的完整命令

Question

我有一些复杂的问题（复杂的意思是我在研究了几个小时后找不到解决方案），问题是：

我向运行（在 SGE 集群上）提交了大量脚本，其中一些脚本生成了 core.# 文件（核心转储文件）。我想我可以用 gdb 打开这些文件，现在当我简单地打开 core.# 文件时，我看到了这个：（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.

现在回答我的问题 - 我需要找到导致崩溃的程序的参数是什么。上面提到的输出仅显示导致崩溃的命令的开头："Core was generated by `/groups/nshomron/artemd/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'."

如果我能看到命令的其余部分，我会解决我的问题，但经过几个小时的在线搜索和检查 gdb 手册后，我找不到任何有用的东西。我尝试用导致崩溃的程序加载 gdb "gdb ..../graphmap core.#"，但我仍然只得到错误命令的开头，无法得到任何其他东西。

任何帮助建议将不胜感激。

更新： 正如用户 @ks1322 所建议的那样 - 我仔细查看了线程。首先我执行 "info threads" 并得到输出：

(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*) ()

它并没有告诉我太多所以我继续寻找 "main thread"。我切换到每个线程，一个一个地执行"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 的第一页上，如下所示：

Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'.

非常感谢来自这里的任何帮助。

最终更新，问题已解决：我听从了@ks1322 的建议并转到了这个 stack overflow thread 然后我重复了第一个答案中描述的内容并且能够获取参数。

（根据我对 gdb 使用的有限知识，简要概述我所理解的内容：首先，您应该检查哪些线程运行正在执行任务，您可以使用 "info threads" 来完成，然后您需要为了检查哪个线程在它的堆栈中有 "main"，我通过使用 "thread #" 一个一个地切换线程并使用 "info stack" 打印堆栈来做到这一点，直到我找到其中有 main 的线程。在我的情况下，它在 "info stack" #9 0x00000000005087fe in main ()" 中显示如下。然后根据链接线程中的说明，我执行了 "set backtrace past-main" 然后 "bt" 然后更改使用命令 "frame #" 将框架转换为包含 "in _start ()" 的框架。几乎完成了，现在我运行命令 "x/8gx $rsp+8" 显示了很少的四行，每行有 2 个收件人。在我的如果第二行看起来像这样“0x7ffe38f872d8：0x00007ffe38f88c35 0x00007ffe38f88c73”现在如果一切正常，这个地址可以包含导致粉碎的命令的参数之一，你可以检查它"x/s" 命令李ke so: "x/s 0x00007ffe38f88c35" 并打印参数。重要说明：我有很多参数，所以我需要转到 "x/8gx $rsp+8" 命令中未显示的后续地址，我注意到地址按常量值（十六进制为 3）递增，所以我手动保存在计算器将“3”添加到地址并使用 x/s 检查地址直到我得到我想要的参数）

非常混乱的解决方案，我希望有人能找到更简单的解决方案，但我只能找到这些。

非常感谢 @ks1322 帮我解决问题并指导我找到解决方案。

Answer 1

您可以使用匹配的二进制文件（为其生成核心转储的二进制文件）加载核心转储，并在 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）。

core.# 文件的 gdb 调试 - 获取导致崩溃的完整命令

gdb debugging of core.# file - getting the full command which caused the crash

linux

gdb

coredump