4. 内存故障注入：通过 memtester、fault-injection 模块模拟位翻转与泄漏

内存故障，说实话，是嵌入式系统里最难排查的问题之一。位翻转、内存泄漏，这些词听起来像是教科书里的概念，但我在实际项目中真真切切被它们坑过——有一次设备在高温环境下跑了三天，突然开始随机崩溃，最后定位到是内存颗粒的软错误。所以这一章，我们来亲手制造这些故障，看看系统到底扛不扛得住。

4.1 内存故障的两大类型

先理清楚我们到底要模拟什么。内存故障从成因上分两大类：

故障类型 典型表现 常见原因
位翻转（Bit Flip） 某一位数据从 0 变 1 或 1 变 0 宇宙射线、电源噪声、温度漂移
内存泄漏（Memory Leak） 已分配内存未释放，可用内存持续减少 编程错误、驱动 bug、第三方库缺陷

位翻转是硬件层面的瞬态故障，泄漏则是软件层面的累积问题。两者都会导致系统行为异常，但检测和防护手段完全不同。

4.2 使用 memtester 模拟位翻转

memtester 是个轻量级工具，专门用来给内存施加压力。我个人习惯把它当作内存稳定性的「试金石」。它本身不会主动注入故障，但通过特定的测试模式，可以暴露内存中已经存在的位翻转问题。

4.2.1 安装与基本用法

# 在 Ubuntu/Debian 上安装
sudo apt-get install memtester

# 基本用法：分配 256MB 内存，运行 5 轮测试
memtester 256M 5

输出会显示每个测试项的结果。如果内存有硬件层面的位翻转，你会看到类似这样的信息：

FAILURE: 0xffffffff != 0xfffffffe at offset 0x00001234
bit flip at address 0x7f8a4b200000

嗯，这里要注意：memtester 报告的是「已经存在的」故障，而不是主动注入。那如果我们想主动制造位翻转呢？往下看。

4.2.2 主动注入位翻转

我建议用一个小技巧——通过修改 memtester 的源码，在测试循环中故意写入错误数据。或者更直接一点，用 devmem2 工具直接操作物理内存地址：

# 读取物理地址 0x10000000 处的值
devmem2 0x10000000

# 写入一个错误值，模拟位翻转
devmem2 0x10000000 w 0xDEADBEEF
⚠️ 警告：直接操作物理内存地址可能导致系统崩溃或数据损坏。务必在测试环境或虚拟机中操作，不要在生产系统上尝试。

4.3 使用 Linux fault-injection 模块

Linux 内核自带了一个强大的故障注入框架——fault-injection。它可以在内核层面模拟各种内存分配失败场景。我在做驱动稳定性测试时，这个模块帮了大忙。

4.3.1 启用内核配置

首先确认内核编译时开启了以下选项：

CONFIG_FAULT_INJECTION=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y

检查当前内核是否支持：

ls /sys/kernel/debug/fail*/

4.3.2 模拟内存分配失败

通过 fail_page_alloc 接口，我们可以让内核在特定概率下返回 NULL：

# 设置 10% 的概率使内存分配失败
echo 10 > /sys/kernel/debug/fail_page_alloc/probability
echo 100 > /sys/kernel/debug/fail_page_alloc/times
echo 0 > /sys/kernel/debug/fail_page_alloc/space
echo 1 > /sys/kernel/debug/fail_page_alloc/task-filter

# 启用故障注入
echo Y > /sys/kernel/debug/fail_page_alloc/task-filter
echo 1 > /sys/kernel/debug/fail_page_alloc/enable

这时候，任何内核态的内存分配都有 10% 的几率失败。你可以运行一个测试程序，观察它是否能正确处理 NULL 返回值。

💡 技巧：我习惯先设置一个较高的概率（比如 50%），快速验证错误处理路径是否覆盖。确认没问题后，再降到 1%~5% 做长时间稳定性测试。

4.4 模拟内存泄漏

内存泄漏的模拟相对简单——写一个程序，不断分配内存但不释放。但关键不在于「制造泄漏」，而在于「检测泄漏」。

4.4.1 手动制造泄漏

#include <stdlib.h>
#include <unistd.h>

int main() {
    while(1) {
        // 每次分配 1MB，永不释放
        void *p = malloc(1024 * 1024);
        if (p == NULL) {
            break;
        }
        // 模拟一些操作
        sleep(1);
    }
    return 0;
}

编译运行后，用 top 或 free -m 观察内存变化：

# 每 2 秒刷新一次，查看内存使用趋势
watch -n 2 free -m

4.4.2 使用 valgrind 检测泄漏

valgrind 是我最常用的内存分析工具。它不需要修改程序，直接插桩运行：

# 检测内存泄漏
valgrind --leak-check=full ./leak_program

# 输出示例
==12345== 1,048,576 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345==    by 0x4005B7: main (leak.c:6)

valgrind 会精确告诉你泄漏了多少字节、在哪个文件哪一行分配的。我曾经靠它在一个遗留项目中揪出了累积泄漏了 2GB 内存的 bug。

4.5 知识体系与核心逻辑

下面这张图梳理了本章的核心脉络：

内存故障注入知识体系 内存故障注入 位翻转模拟 内存泄漏模拟 memtester 压力测试 devmem2 直接注入 手动分配不释放 valgrind 检测 内核 fault-injection fail_page_alloc 接口 核心目标 验证系统在内存故障下的行为：错误处理路径是否触发？ 系统是否崩溃？数据是否损坏？恢复机制是否生效？

4.6 实战：组合测试场景

把上面学到的工具组合起来，做一个完整的测试流程。我个人建议按这个步骤来：

  1. 基线采集：用 free -m 和 /proc/meminfo 记录正常状态下的内存数据。
  2. 位翻转注入：用 memtester 或 devmem2 在特定地址制造位翻转。
  3. 观察系统反应：检查内核日志（dmesg），看是否有 ECC 纠错记录或 panic。
  4. 内存泄漏模拟：运行泄漏程序，同时用 valgrind 监控泄漏量。
  5. 内核分配失败：启用 fail_page_alloc，运行驱动或应用，观察错误处理。
  6. 结果分析：对比基线，评估系统的健壮性。

📌 关键指标：

  • 位翻转后系统是否能在 1 秒内恢复？
  • 内存泄漏达到多少时系统触发 OOM Killer？
  • 内核分配失败时，驱动是否返回了合理的错误码？

4.7 避坑指南

最后分享几个我踩过的坑：

  • 我曾经在虚拟机里做 memtester 测试，结果发现虚拟化层把物理地址映射搞乱了，测试结果完全不可信。后来我改用裸机或带硬件直通的虚拟机。
  • fault-injection 的 task-filter 默认是关闭的，如果不开启，它会影响到所有进程，包括系统关键服务。我建议先指定目标进程的 PID。
  • valgrind 会大幅降低程序运行速度（5~20 倍），所以不适合做性能测试，只适合做功能验证。

内存故障注入不是目的，目的是让系统在故障面前「不崩溃、不丢数据、能恢复」。你想想看，如果连内存位翻转都扛不住，那设备在工业现场、航天器上怎么敢用？

← 上一章 📖 返回目录 下一章 →