一个偶发测试救了生产环境：Buildkite 顺着 Redis 丢消息，挖出 C 扩展的内存地雷
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
据 Buildkite 工程团队复盘，一次 Redis 客户端升级后，原本稳定的功能测试开始偶发失败。团队最初以为是 WebSocket 时序问题，最后借助 core dump 和 AddressSanitizer 定位到 redis-client 所带 C 扩展中的 heap use-after-free：读取线程会在特定竞态下释放写入线程仍要使用的缓冲区。
一句话结论： Flaky test 不一定只是测试写得烂；当失败突然集中出现在依赖升级之后，它可能是生产环境尚未爆炸的内存错误，关键是把“偶发”变成可统计、可保留现场的信号。
故事开始得很普通。几个测试从接近 100% 可靠突然变得不稳定，严重到阻塞主分支部署。团队先临时排除测试，让发布恢复，再查看 Test Engine 的历史可靠性，发现变化恰好出现在一次 Redis gem 升级之后。这个时间关联没有证明因果，却给了调查一个比“再跑一次看看”更好的方向。
最初的假设仍是常见的网络竞态。测试涉及 RSpec、Selenium、Web/API 服务、数据库、Redis 和 ActionCable，任何一环慢几十毫秒，都可能让断言早于 WebSocket 消息到达。开发者尝试加入等待，随后又发现订阅命令到了 ActionCable，却没有抵达 Redis；日常开发环境里也有人遇到 WebSocket 偶尔失效。
真正改变调查方向的是一条罕见的 double free 报错，随后另一轮测试触发 segmentation fault。恰好，团队以前写过一个插件，会在崩溃时自动把 core dump 上传为构建产物。这个“黑匣子”显示崩溃发生在 hiredis C 扩展的 memmove，其长度参数离谱到约 45PB。到这里，问题已经不像消息延迟，而像内存被更早的代码破坏。
团队把可复现程序放进带 ASAN 的 Ruby 环境。半小时内，ASAN 报告 heap use-after-free。该连接使用读、写两个线程并发工作，在某些关闭与缓冲区状态组合下，reader 释放了 writer 仍在使用的内存。崩溃只是较晚的表现，真正的错误发生在更早时刻，这也是普通堆栈很难找出原因的地方。
临时处置不是在业务代码里加更多 sleep，而是在测试、开发和生产环境禁用该 C 扩展，改走更安全的实现，并向上游提交可复现用例。Buildkite 表示没有生产数据因此受损。这并不意味着 C 扩展不该用，而是原生扩展一旦越过语言运行时的内存安全边界，排查和风险等级都会改变。
这篇复盘对开发团队最有价值的，不是一句“使用 ASAN”。ASAN 只有在已有复现、正确运行时和足够执行次数时才发挥作用。真正串起答案的是测试可靠性历史、升级时间线、跨环境症状、自动保存 core dump，以及有人愿意继续追一条看似烦人的偶发失败。
关键事实
- 问题在 Redis gem 升级后出现，影响 ActionCable 相关测试和开发环境 WebSocket。
- core dump 指向 hiredis C 扩展，ASAN 最终确认 heap use-after-free。
- 根因是读取线程在特定情况下释放写入线程仍在使用的缓冲区；团队先禁用 C 扩展并向上游报告。
OC 判断
把 flaky test 一律重跑或隔离，会让测试面板变绿，也可能抹掉系统唯一的预警。真正成熟的做法是区分“长期随机噪声”和“某次变更后可靠性突降”，后者应该像生产告警一样被调查。
为什么重要
- 对开发者： 为崩溃自动保存 core dump，并在原生扩展上准备 ASAN 等工具链。
- 对企业： 测试可靠性趋势比单次通过率更能发现依赖升级带来的风险。
- 对用户： 一些最严重的底层漏洞，最初可能只表现为页面偶尔收不到实时消息。
评论
围绕这篇文章补充信息、提出问题或分享观察。