从 Linux 上的核心转储中找到崩溃的汇编指令答案

【问题标题】：Find the crashing assembly instruction from core dump on Linux从 Linux 上的核心转储中找到崩溃的汇编指令
【发布时间】：2016-01-19 09:09:03
【问题描述】：

如果我将崩溃程序和核心转储加载到gdb，它会显示如下堆栈跟踪和崩溃点。

Core was generated by `./cut --output-d=: -b1,1234567890- /dev/fd/63'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  is_printable_field (i=1234567890) at src/cut.c:266
266   return (printable_field[n] >> (i % CHAR_BIT)) & 1;
(gdb) bt
#0  is_printable_field (i=1234567890) at src/cut.c:266
#1  set_fields (fieldstr=0x7ffccb0561c4 "") at src/cut.c:533
#2  main (argc=4, argv=0x7ffccb055cf8) at src/cut.c:865

有没有办法知道导致段错误的确切汇编指令？

【问题讨论】：

@terencehill 反汇编高级行可能会产生多个汇编指令。
也许你可以试试layout asm，然后一步一步直到程序崩溃。
如果不需要从 gdb 完成，那么在valgrind 下运行会有所帮助
如果某个答案解决了您的问题或对您有所帮助，请考虑接受，另见：meta.stackexchange.com/questions/5234/…

标签： linux segmentation-fault coredump

【解决方案1】：

一种可能性是设置：

(gdb)layout asm

当 GDB 停止时，相应的流水线被指向。

例子：

   │0x7ffff7aa441d <strtok+45>      je     0x7ffff7aa44d6 <strtok+230>                                                                                       │
   │0x7ffff7aa4423 <strtok+51>      mov    %rsi,%rax                                                                                                         │
  >│0x7ffff7aa4426 <strtok+54>      mov    (%rax),%cl                                                                                                        │
   │0x7ffff7aa4428 <strtok+56>      test   %cl,%cl                                                                                                           │
   │0x7ffff7aa442a <strtok+58>      je     0x7ffff7aa4454 <strtok+100>


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7aa4426 in strtok () from /lib64/libc.so.6
(gdb)

【讨论】：

【解决方案2】：

您可以使用disassemble GDB 命令。也可能在$rip 上使用x/i（x86-64 上的程序计数器）

但是，在您的情况下，假设代码是 C 语言（不是带有一些 operator [] 的 C++），唯一可能的罪魁祸首是 printable_field 指针或 n 索引。

考虑同时使用valgrind 和/或使用-fsanitize=... 选项编译（除了-g -Wall 选项到最近的GCC 编译器），特别是-fsanitize=address 或-fsanitize=undefined...

【讨论】：

反汇编高级行可能会产生多个汇编指令。我怎么知道罪魁祸首是谁？
是的，我很清楚i 已被设置为一个非常高的值。但是，有没有办法查明生成 SIGSEGV 的错误指令？
GDB disassemble 命令在大型函数上几乎没用。我的功能大约有 75 页，我不知道我是否不小心错过了==>，或者它是否即将出现。天才认为总是从函数的开始拆解是个好主意；并且不提供disassemble .（其中点是“这里”）。