从崩溃难题看 C 标准库与 Rust：线程安全问题引发的深度思考

在软件开发的世界里，每一次技术的变革和尝试都伴随着未知的挑战。EdgeDB 团队在将部分网络 I/O 代码从 Python 迁移到 Rust 的过程中，就遭遇了一场棘手的问题，这个问题不仅暴露了 C 标准库的线程安全隐患，也让我们对 Rust 的 “安全特性” 有了新的认识。

EdgeDB 正在为产品开发一个新的 HTTP 获取功能，选用reqwest作为 HTTP 客户端库。起初，一切进展顺利。在本地开发环境中，功能正常运行，在 x86_64 架构的 CI（持续集成）运行器上，各项测试也顺利通过，看起来十分稳定。然而，当测试在 ARM64 架构的 CI 运行器上进行时，奇怪的事情发生了。

测试开始间歇性失败，测试运行器启动后，会无限期地挂起，然后 CI 任务超时。从日志中看不到任何错误信息，只显示某个测试一直在运行。几个小时后，任务最终以超时错误结束。最初，团队以为是死锁问题，毕竟测试进程毫无响应的表现很符合死锁的特征。但深入调查后发现，事情远没有这么简单。

为了找出问题所在，团队成员决定直接连接到 ARM64 运行器一探究竟。由于 CI 机器运行在亚马逊 AWS 上，这使得他们可以获得真实的、非容器化的 root 用户权限，方便查看系统日志。一番查找后发现，测试进程并非死锁，而是直接崩溃了。只不过测试运行器没有检测到这一情况，这也成为了后续需要解决的另一个问题。

通过journalctl命令，团队找到了进程的核心转储文件，将其加载到gdb调试工具中。但一开始，由于缺少相关文件，调试过程遇到了诸多错误。经过一番操作，将相关库文件从容器中复制出来并配置好gdb后，终于得到了有用的回溯信息。令人意外的是，崩溃并非发生在新开发的 HTTP 代码中，而是出现在getenv函数里。

getenv函数用于获取环境变量的值，从回溯信息来看，它在扫描感兴趣的环境变量时，尝试从一个无效的内存位置加载数据，从而导致崩溃。但这就引发了新的疑问：为什么会出现这种情况呢？毕竟，环境变量看起来是完全有效的。

在深入调查过程中，团队成员 Yury 提供了关键线索。他指出，可能是文件 I/O 相关操作出错，Python 试图根据errno构建异常，这一过程调用了gettext，进而触发了getenv。而getenv在多线程环境中并非安全函数，这很可能就是问题的根源。

为了验证这一猜测，团队开始检查环境块。environ是 POSIX 标准定义的一个char **类型的变量，本质上是一个指向环境字符串的指针列表，列表末尾用NULL指针标记。通过gdb查看，环境块看起来并没有明显异常。但进一步分析发现，getenv函数中用于遍历environ数组的指针x20，其值与environ实际地址相差近 60MB。对比两个内存区域的指针值，发现它们在SSL_CERT_FILE和SSL_CERT_DIR这两个环境变量处开始出现差异。这强烈暗示了存在竞态条件，另一个线程在调用setenv时修改了environ。

setenv用于设置环境变量，在多线程环境中调用它存在风险。当环境块的内存空间不足时，setenv可能会调用realloc重新分配内存，而此时如果另一个线程正在调用getenv，就可能导致数据不一致，引发崩溃。

那么，是哪段代码在调用setenv呢？经过一番谷歌搜索，团队发现问题可能出在openssl-probe上。openssl-probe会设置SSL_CERT_FILE和SSL_CERT_DIR这两个环境变量，而 EdgeDB 在 Linux 上使用的rust-native-tls的openssl后端会调用这些函数。查看openssl-probe库的代码可以发现，它在设置环境变量时，没有考虑到多线程环境下的安全性。

问题找到了，那如何解决呢？EdgeDB 团队最终决定在 Linux 上放弃使用reqwest的rust-native-tls/openssl后端，转而采用rustls。虽然最初选择rust-native-tls是为了避免在将 Python 代码移植到 Rust 时同时引入两个 TLS 引擎，但考虑到当前的线程安全问题，短期内使用两个引擎也成为了无奈之举。

此外，还有另一种解决思路，即在调用try_init_ssl_cert_env_vars时，持有 Python 的全局解释器锁（GIL）。Rust 本身有内部锁来防止 Rust 代码在读写环境变量时出现竞态条件，但无法阻止其他语言的代码直接使用libc。持有 GIL 可以避免与 Python 线程产生竞争。

值得一提的是，Rust 项目已经意识到了这一问题，并计划在 2024 版中将环境设置函数标记为不安全。而 glibc 项目也在近期对getenv函数进行了改进，通过避免realloc和泄漏旧环境，增加了其线程安全性。

这次事件为开发者们敲响了警钟。在多线程编程中，即使使用了像 Rust 这样强调安全性的语言，也不能忽视底层 C 标准库带来的风险。C 标准库中的一些函数，如setenv和getenv，在多线程环境下的不安全性可能会引发难以排查的问题。

对于 Rust 开发者来说，虽然 Rust 提供了强大的安全机制，但在与其他语言交互或使用底层库时，仍需谨慎对待。特别是在涉及到多线程操作时，要充分考虑不同语言和库之间的兼容性和线程安全性。

在实际开发中，我们往往会依赖各种库来实现功能，但这些库可能隐藏着潜在的风险。就像这次 EdgeDB 遇到的问题，openssl-probe看似无害的代码，却在多线程环境下引发了严重的崩溃。因此，在选择和使用库时，开发者需要深入了解其内部实现，评估潜在风险，尤其是在关键业务场景中，更要确保代码的稳定性和安全性。

同时，这也反映出跨语言开发的复杂性。不同语言有不同的特性和规范，在混合使用时，需要特别注意边界情况和交互细节。在 EdgeDB 的案例中，Rust 代码与 Python 代码以及底层 C 标准库之间的交互出现了问题，导致了崩溃。这提醒我们，在跨语言开发项目中，要建立完善的测试机制，覆盖各种可能的情况，及时发现并解决潜在问题。

从更广泛的角度看，这次事件也为整个软件开发社区提供了宝贵的经验教训。无论是语言开发者还是库开发者，都应该更加重视多线程环境下的安全性问题。语言标准的制定者可以考虑进一步完善标准库的设计，提供更安全的接口；库开发者在编写代码时，要充分考虑多线程场景，确保库的线程安全性，减少类似问题的发生。

在软件开发的道路上，每一次遇到的问题都是一次成长的机会。EdgeDB 团队通过这次经历，不仅解决了当前的技术难题，也为未来的开发积累了宝贵的经验。希望其他开发者能够从这个案例中汲取教训，在开发过程中更加注重细节，避免陷入类似的困境。你在开发中遇到过哪些因库的不安全性导致的问题呢？欢迎在评论区分享你的经验和看法。