嵌入式core dump使用（避雷心经Coredump排查入门）

嵌入式core dump使用（避雷心经Coredump排查入门）3.键入 f {num} 可切换至指定的一帧，从而打印该阶段的相关信息。2.键入 bt （backtrace）打印函数调用栈，第一行即为发生 Core 的最后调用处。# 查看当前 Corefile 大小，为0则表示禁止产生 Corefileulimit -c# 设置 Corefile 大小无限大ulimit -c unlimited# 设置 Corefile 大小1024kbulimit -c 1024GDB（GNU Debugger）是 GNU 软件系统中的标准调试器，具备各种调试功能，包括但不限于打断点、单步执行、打印变量、查看寄存器、查看函数调用堆栈等，能够有效地针对函数的运行进行追踪，也常用于 Coredump 分析。1.运行 gdb [executable file] [corefile] 开始调试，执行 corefile 需要对应的可执行文件：

作者：garrycai，腾讯PCG后台开发工程师

| 导语 想必每一位 C 选手在工作中都难免会踩中 Coredump 地雷，而我作为 C 新手也与 Coredump 有过激烈的战斗，下文正是我在排查 Coredump 过程中总结的一些心得经验。

1. 概念

Coredump（核心存储）是进程异常终止或崩溃时的内存快照，操作系统会在程序发生异常而异常在进程内部又没有被捕获的情况下，会把进程此刻内存、寄存器状态、堆栈指针、内存管理信息以及函数调用堆栈等信息转储保存在一个文件里（Corefile）。Coredump 对于开发者诊断和调试程序是非常有帮助的，因为对于有些程序错误很难重现，例如偶发的指针越界，而 Corefile 可以再现程序出错时的情景。

2. 工具2.1 Coredump 开启

有时进程 Core 了却没有找到 Corefile，有可能是因为没有开启 Coredump，可通过 ulimit 命令开启：

# 查看当前 Corefile 大小，为0则表示禁止产生 Corefile
ulimit -c
# 设置 Corefile 大小无限大
ulimit -c unlimited
# 设置 Corefile 大小1024kb
ulimit -c 1024

2.2 GDB 工具2.2.1 概念

GDB（GNU Debugger）是 GNU 软件系统中的标准调试器，具备各种调试功能，包括但不限于打断点、单步执行、打印变量、查看寄存器、查看函数调用堆栈等，能够有效地针对函数的运行进行追踪，也常用于 Coredump 分析。

2.2.2 GDB 分析 Corefile

1.运行 gdb [executable file] [corefile] 开始调试，执行 corefile 需要对应的可执行文件：

2.键入 bt （backtrace）打印函数调用栈，第一行即为发生 Core 的最后调用处。

3.键入 f {num} 可切换至指定的一帧，从而打印该阶段的相关信息。

4.其他常用命令

命令	作用
print {variable}	打印当前函数的指定变量值
info args	打印出当前函数的参数名及其值
info locals	打印出当前函数中所有局部变量及其值
disas	查看当前栈帧的汇编代码

2.2.3 GDB单步调试网络程序

1. gdb -p {进程pid}：使GDB监听某个进程。

2. b {Class::func}：给某个可疑函数打断点。

3. 客户端请求网络服务。
4. c (continue)：运行程序，会停在断点处

5. n (next)：一行一行运行代码，如果遇到core会报错，此时便可通过bt、print去排查core。（其它命令：until：跳出循环、finish：执行完当前函数）

更多GDB使用：GDB调试

2.3 AddressSanitizer 工具2.3.1 概念

很多时候通过 GDB 调试 Corefile 看出的只是 Core 的表象原因，例如通过 GDB 看出 Core 的直接原因是 NULL 指针引用，但真正的问题是这些不应该为 NULL 的指针为何被赋值成 NULL。在如今异步和多线程编程的场景下，很难只从函数调用栈中分析出原因。而 AddressSanitizer 工具正是针对这类问题的一把利器，用来探测内存访问的 bug，包括了缓冲区溢出、重复使用已被释放的堆内存等。

2.3.2 使用

1.安装依赖 sudo yum install libasan

2.在项目根目录添加“.bazelrc”文件

3.在“.bazelrc”文件中配置以下内容

build --copt=-g build --copt=-Og // 禁用gcc优化，方便排查问题 build --copt=-ggdb build --strip=never build --copt=-fno-omit-frame-pointer build --copt=-fsanitize-recover=address // 检测到错误后，不退出，继续执行（需要配合环境变量配置） build --copt=-fsanitize=address // 打开AddressSanitizer模块（LeakSanitizer、MemorySanitizer实际上也都整合到了这里） build --linkopt=-fsanitize=address

4.编译程序，并将程序上传到测试容器，测试容器安装依赖 sudo yum install libasan

5.因为通过123无法正常启动会一直重启，建议停止容器，避免干扰

6.测试容器中启动程序，观察 std out

export LD_PRELOAD=/lib64/libasan.so.4 export ASAN_OPTIONS=halt_on_error=0 // 检测到错误后，不退出，继续执行（框架或者某些库可能会运行到我们的关注点之前就报错）3. 实践3.1 WebQO 下线老紧密度算子引起的 Coredump3.1.1 背景

WebQO 是搜狗搜索引擎依赖的 Query 理解系统模块，其主要提供切词、词权、紧密度、意图识别的功能。因为项目过于悠久，WebQO 上冗余了两个紧密度算子，据分析，老紧密度算子结果处于无人使用废弃状态，于是我便打算下线老紧密度算子，欲降低系统复杂度与提升性能。

3.1.2. Coredump 情景回顾

因为主流程仅调用了老紧密度算子对外提供 run() 接口，所以我下意识地认为注释掉这行调用代码即完成了算子的下线。

但事情往往没那么简单，在我提交测试后，发现每次对服务请求都会 Coredump，无法获取响应结果。

3.1.3. 原因分析

1.使用 GDB 对 Corefile 进行分析，键入 bt 显示 Coredump 时的堆栈。

2.堆栈的第一行即为发生 Coredump 时的最后调用处，咱们定位到其对应的代码，这个函数的作用是用新紧密度算子的结果替换掉老紧密度算子的结果。从代码可以看出这里很有可能是数组越界访问的问题，访问了非法地址。我们会产生一个疑问：ngram_nodes这个数组会不会压根不存在 或者 长度与 seginfo.termsCount 不一致？

3.带着上面的疑问，我们可以先通过 GDB 打印 ngram_nodes 的值，可以看到数组的长度为0，验证了我们的猜想。

4.再结合代码分析，我们直接搜索 ngram_nodes 被赋值的地方，果不其然，ngram_nodes 数组是在老紧密度算子里被赋值的。当我把老紧密度算子调用注释掉后，该数组无元素，而上图函数的 for 循环条件是依据 term 的个数，而非 ngram_nodes 的数组长度，从而导致的数组访问越界。

3.1.4. 解决思路3.1.4.1. 做好防御

在原来代码中，for 循环对两个数组（seginfo.terms & ngram_nodes）都进行了遍历，因为在原逻辑中默认两个数组长度是一致的，所以原作者设置的循环条件只是 seginfo.terms 的长度。 但是这种做法不够安全，因为当 ngram_nodes 的长度小于 seginfo.terms 时会发生数组越界。因此这里的循环条件应该是 i < min(seginfo.terms长度 ngram_nodes数组长度)。

但是该方案并不足以满足业务需求，因为如此修改后会进入不了 for 循环，也就无法对 ngram_nodes.adjoin 进行赋值。

3.1.4.2. 预分配内存

因为老紧密度结果的 adjoin 字段还在被下游服务使用，这里需要进入 for 循环将新紧密度值赋给 adjoin 字段。所以更合理的思路是对 ngram_nodes 数组预分配内存，使其与 seginfo.termsCount 保持一致长度。

3.1.5. 小结

这类 Coredump 算是较简单的必现型 Coredump，其 Coredump 原因在于业务功能冗余的情况下又没做好细节防御，从而在 ngram_nodes 数组长度变动时导致了数组访问越界。

3.2. 修改 QU_Platform 业务配置引起的 Coredump3.2.1. 背景

QU_Platform 是搜索中台下的 Query 理解系统平台，其下囊括了众多 QU 算子服务，如切词、同义词、意图等。

3.2.2. Coredump 情景回顾

鹰眼日志上报在配置中是默认开启的，当我在线上修改了服务的业务配置后，便产生了 Coredump。这个 Coredump 是偶发性的，集群中并非所有节点都 Coredump。

3.2.3. 原因分析

1.使用 GDB 对 Corefile 进行分析，键入 f 0 显示发生 Coredump 时的堆栈首行。

2.从堆栈信息可以看出，程序在调 atta_api 时发生 Coredump。结合我修改配置的操作，以及并非所有服务都 Coredump 的特点来看，这里有可能是我修改配置后触发某些逻辑，而与此同时服务正好在上报鹰眼日志，从而导致了多线程冲突问题。

3.结合代码进行分析，在我修改了鹰眼日志上报的配置后，触发了 AttaReporter::ReInit() 函数，此函数会对 atta_client_ 做 release() 操作。

而与此同时，一个检索请求触发了 AttaReporter::Report() 调用 atta_client_→send_string()，而因为 atta_client_ 在此时已经被被析构了，这便产生了 Coredump。

3.2.4. 解决思路3.2.4.1. 删除 ReInit 功能

当前考虑到 atta_conf 的配置几乎不用变动，所以采取直接删除 ReInit 功能的做法，这样其他业务配置修改时就不会影响到 AttaReport 上报日志。此做法下，如果改动了 atta_conf 配置，需要重启服务才能生效。

3.2.4.2. 加互斥锁

另一种方法就是给 atta_client_ 加互斥锁，在 ReInit() 和 Report() 时都去申请该互斥锁，避免冲突。但这导致：即使不是 atta_conf 的配置更新，也会判断该申请锁逻辑，带来一定的性能损耗。

3.2.5. 小结

这类 Coredump 是稍复杂的偶现型 Coredump，其 Coredump 原因在于没有对存在多线程竞争的资源做保护，可通过对竞争资源加锁保护解决，或者放弃写功能，使该资源只可读。

4. 总结

在经历了一些 Coredump 的折磨后，我也从中学习积累了一些常见的 Coredump 场景以及应对办法，以后再遇到 Coredump 可以参照历史经验并按照下述步骤进行排查。

4.1. 常见 Coredump 场景

1.内存访问越界。

• 由于使用错误的下标，导致数组访问越界

• 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符

• 使用 strcpy strcat sprintf 等字符串操作函数，将目标字符串读/写爆。应该使用 strncpy strncat snprintf 等函数防止读写越界。

2.多线程问题

• 多线程读写的数据未加锁保护

• 多线程程序使用了线程不安全的函数

• 智能指针多重析构

3.非法指针

• 空指针访问

• 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为 bus error 而 Coredump。

4.堆栈溢出

• 不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

5.格式化输出时数据类型错误

• 例如输出日志时，将整型数据用字符串输出

4.2. Coredump 排查步骤

1. 先深呼吸一口，调整下心态，催眠自己的内心：“真好，又获得了一次学习的机会”。
2. 服务应急措施。如果 Coredump 影响了线上服务，服务该扩容扩容，该重启重启。
3. 保存 Coredump 现场。千万不要头脑一热就把原来 Coredump 的节点直接删掉，可停止 Coredump 的节点，便于事后分析修复。
4. 梳理记录发生 Coredump 前的行为，任何举动都可能成为有价值的排查信息。
5. 使用 GDB 对 Corefile 进行分析，定位 Coredump 的代码位置，缩小排查范围。并结合代码等信息进行分析。如果仅通过 Corefile 无法确认 Coredump 的时机，也可参照 3.2.3 单步调试网络程序。
6. 若 GDB 无法解决当前问题，尝试使用 AddressSanitizer 工具深入排查。

以上便是我作为 C 新手在踩了 Coredump 地雷后收获的经验，希望能给读者带来一些帮助，避免重复踩坑。