什么是段故障rip/rsp编号以及如何使用它们

Question

当我的linux应用程序崩溃时，它会在日志中生成类似以下内容的一行：

0000000的段错误rip 00003f32a823 rsp 000123ade323错误4

这些rip和rsp地址是什么？我如何使用它们来定位问题呢？它们是否对应于"objdump“或"readelf”输出中的内容？如果我的程序将其符号剥离出来(放到一个单独的文件中，该文件可以通过gdb使用)，它们是否有用？

Answer 1

rip指针告诉你导致崩溃的指令。您需要在地图文件中查找它。

在映射文件中，您将拥有函数及其起始地址的列表。当您加载应用程序时，它被加载到一个基地址。rip指针-基地址为您提供映射文件地址。然后，如果您在映射文件中搜索一个函数，该函数的起始地址略低于您的rip指针，并且在列表中，后面是一个地址更高的函数，则您已经找到了崩溃的函数。

然后，您需要尝试找出代码中的错误所在。这并不是很有趣，但至少给了你一个起点。

编辑："segfault“位告诉你，我敢打赌，你已经解引用了一个空指针。rsp是当前的堆栈指针。遗憾的是，它可能并不都那么有用。有了内存转储，你“也许”能够更准确地计算出你在函数中的位置，但它可能真的很难准确地计算出你在优化的构建中的位置

Answer 2

我也得到了这个错误。当我看到：

probe.out[28503]: segfault at 0000000000000180 rip 00000000004450c0 rsp 00007fff4d508178 error 4

probe.out是一个使用libavformat (ffmpeg)的应用程序。我把它拆开了。

objdump -d probe.out

rip是运行指令的位置：

00000000004450c0 <ff_rtp_queued_packet_time>:
  4450c0:       48 8b 97 80 01 00 00    mov    0x180(%rdi),%rdx
  44d25d:       e8 5e 7e ff ff          callq  4450c0 <ff_rtp_queued_packet_time>

最后，我发现应用程序在函数ff_rtp_queued_packet_time中崩溃了

PS。有时地址并不完全匹配，但它几乎就在那里。