当我的 linux 应用程序崩溃时，它会在日志中产生如下一行：
段错误在 0000000 rip 00003f32a823 rsp 000123ade323 错误 4
那些 rip 和 rsp 地址是什么？我如何使用它们来查明问题？它们是否对应于“objdump”或“readelf”输出中的某些内容？如果我的程序将其符号剥离（到单独的文件，可以使用 gdb 使用），它们是否有用
【问题讨论】：
标签： debugging segmentation-fault
那么 rip 指针会告诉您导致崩溃的指令。您需要在地图文件中查找它。
在映射文件中，您将有一个函数列表及其起始地址。当您加载应用程序时，它被加载到一个基地址。 rip 指针 - 基地址为您提供映射文件地址。然后，如果您在映射文件中搜索一个函数，该函数的起始地址略低于您的 rip 指针，然后在列表中，后面是一个地址较高的函数，您已经找到了崩溃的函数。
您需要从那里尝试找出代码中出了什么问题。它不是很有趣，但它至少为您提供了一个起点。
编辑：“segfault at”位告诉您，我敢打赌，您已取消引用 NULL 指针。 rsp 是当前堆栈指针。唉，它可能不是那么有用。通过内存转储，您“可能”能够更准确地确定函数中的位置，但很难准确地确定优化构建中的位置
【讨论】：
我也得到了错误。当我看到：
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。有时地址不完全匹配，但几乎就在那里。
【讨论】：