本教程向您展示了如何利用 OpenResty XRay 对崩溃的 OpenResty/Nginx 应用的 core dump 文件进行自动和全面的分析。OpenResty XRay 可以为您生成一份详细的分析报告，涵盖了 C 和 Lua 的调用栈轨迹、Lua 的 GC 对象引用图、Lua 协程、并发的 HTTP 请求和 libc 的内存分配。它利用动态跟踪和火焰图的强大功能，对死亡进程即 core dump 文件进行分析，帮助您快速找出线上应用崩溃的根因。

查看 core dump 文件

运行 ls 命令，列出当前目录下面的所有文件。

这里发现了一个新的 core dump 文件。新的 core 文件不是一定存放在这个目录下，只是我们的应用提前配置好了用这个目录存放。

运行 readlink 命令查看该文件的绝对路径。

下面我们将使用 OpenResty XRay 对这个 core 文件进行实时分析，找出进程崩溃的原因和上下文信息。 复制这个 core 文件的路径。

使用 OpenResty XRay 的引导式分析功能分析 core dump 文件

在浏览器中打开 OpenResty XRay 的 Web 控制台。

确保当前分析的机器是正确的。

如果不对，我们可以在下面的列表重新选择。

进入 “Guided Analysis” 页面。

这里可以看到系统能分析的不同类型的问题。

选择 “Core dumps or process crashes”.

点击 “Next”.

把我们刚刚复制的 core 文件路径名粘贴到这里。

OpenResty XRay 会自动从这个 core 文件提取可执行文件路径，并显示到这个文本框里。

确保应用的类型是正确的。通常默认值就是对的。

开始分析。系统正在执行分析。

分析完成，正在生成报告。

可以看到自动生成了一份分析报告。

报告右上方显示了 core 文件的路径和生成时间。

我们先看一下执行上下文。

看看机器码层面的信息。

可以看到进程被信号 SEGV 中止。

下面是对这个信号的详细解释。SEGV 的中文翻译是“段错误”，当一个程序试图访问的内存区域没有权限，或者根本不存在时，就会产生该信号。

这里列出了当前执行指令附近的反汇编代码。

这一行是当前正在执行的指令，可以通过该行指令前面的红色箭头识别。正是在执行这条指令时发生了段错误，

而这条指令正在读取一个内存地址。

这是 core dump 发生时 CPU 寄存器的值。

这里是崩溃发生时的 C 调用栈轨迹.

这个函数是 GNU C 库中的一个函数，用于实现内存复制操作。

这是 LuaJIT 中的一个函数，它执行 FFI 元表的索引操作。

ngx_http_lua_run_thread 运行 Nginx 中的 Lua 协程。

ngx_http_core_content_phase 执行 Nginx 的内容处理阶段。

这里是当前正在执行的 Lua 调用栈轨迹.

这个 C 函数是在进行内存复制。我们在 C 调用栈轨迹中已经看到过这个函数。

这两个元方法会在访问 cdata 内部的字段成员时被调用。

decode_order_data 是业务代码里的 Lua 函数。

点击 “More” 查看更多细节。

上面的调用栈轨迹是从这个 Lua CPU 火焰图自动推导出来的。

下面是完整的调用栈轨迹，包含了每一个 Lua 函数帧里的所有参数和局部变量的值。

点击这里可以查看函数 decode_order_data 的所有局部变量和参数变量。

让我们回到业务级别函数 decode_order_data 上来。把鼠标放在函数的绿色框上。

可以看到这个函数的源文件名。在提示框中还可以看到文件的完整路径。

源代码行号是 79。

点击这个图标，复制这个函数完整的源文件路径。

使用 vim 编辑器打开源文件，查看这个文件里的 Lua 代码。您可以使用任何您喜欢的编辑器。

正如 OpenResty XRay 建议的那样跳转到第 79 行。

由于 order_cdata 可能为空指针，程序在访问它的 user_id 字段时发生了段错误并崩溃。因此，访问之前应该先判断 order_cdata 是否为空指针。

从这里可以看到这行代码也确实在 decode_order_data 函数中，正如之前报告中提到的。

这是在所有仍然存活着的 LuaJIT 协程中最常见的调用栈轨迹。

sleep 是 C 语言中的一个函数，用于将当前线程的执行暂停一段时间。

这里显示了崩溃发生时正在处理的所有 HTTP 请求。

这是崩溃发生时，Nginx 进程正在处理的那一个 HTTP 请求的信息。

这里显示了发起请求的客户端的 IP 地址。

请求方法是 POST。

这是请求的 URI。

我们可以进一步查看所有其他并发的 HTTP 请求。

报告中还包含了内存分析。

这是 Lua GC 对象内存分布的最热数据引用路径。

该路径的意思是：前往 registry 注册表，

找到 _LOADED 表，

在其中找到 engines.sre.sre_lib 模块，

并在该模块中，访问 run_rules 函数或数据。

这条路径是从这个 Lua GC 对象内存分布火焰图中自动推导出来的。

全自动分析与报告

OpenResty XRay 还可以监控线上应用产生的任何新的 core dump，分析这些文件，并自动生成分析报告。切换到 “Insights” 页面，

您可以在 “Insights” 页面中找到以日和周为周期的自动报告。

所以您不是非得用 “Guided Analysis” 功能。当然，“Guided Analysis” 对于应用的开发和演示是很有用的。

关于 OpenResty XRay

OpenResty XRay 是一个动态追踪产品，它可以自动分析运行中的应用程序，以解决性能问题、行为问题和安全漏洞，并提供可行的建议。在底层实现上，OpenResty XRay 由我们的 Y 语言驱动，可以在不同环境下支持多种不同的运行时，如 Stap+、eBPF+、GDB 和 ODB。

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴, 是 “边缘计算“、”动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。

关注我们

如果您喜欢本文，欢迎关注我们 OpenResty Inc. 公司的博客网站 。也欢迎扫码关注我们的微信公众号：

翻译

我们提供了英文版原文和中译版（本文）。我们也欢迎读者提供其他语言的翻译版本，只要是全文翻译不带省略，我们都将会考虑采用，非常感谢！