Challenge

C/C++ 提供了直接操作内存的强大能力，然而使用不当也会招致许多问题，下面是 Google chromium 团队的一组统计数据:

"Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs."

与内存相关的问题往往排查难度较大，耗时较多。网易云信的 IM、RTC 等 SDK 都是使用 C/C++ 来进行开发的，作为软件供应商，网易云信面临的挑战更大:

需要支持更多的操作系统；
需要支持更多的开发框架。

上述挑战促使我们使用更强大、更通用的 Sanitizer 工具来帮助工程师快速排查与定位内存问题，提高生产力，本系列文章共四篇，旨在向读者介绍网易云信的工程实践，本文为第一篇。

Sanitizers 简介

Sanitizers 是由 Google 研发团队提出的用于检测 C/C++ 程序常见内存错误的工具集，Google 工程师公开了它们的源代码和算法：

github.com/google/sani…

并在 LLVM clang 上实现，它们已经被用于多个工程中。比如 Chromium、Firefox 等知名项目中。

下表汇总整理了 Sanitizers 的各个工具和它们的作用：

表1.png

从表格的内容可以看出，Sanitizers 除了能够检测内存错误外，还能够检测一些其它常见的错误。后面笔者将分章节介绍上述几种 Sanitizer 的用法与原理。

Sanitizers 的优势

当前市面上存在着多种用于检测内存错误的工具，在投入生产使用之前，可以从如下维度来评估:

表2.png

在后续介绍各种 Sanitizer 工具时，会从上述几个维度进行介绍。Sanitizer 并不是第一个被发明出来用于检测内存错误的工具，在它之前，同类的工具已经非常多了，Sanitizer 其实是在前人的成果上改进加创新而来，因此它在上述几个方面比起同类工具有着优势。

Sanitizers 具备如下优势:

与 Compiler 集成，主流 IDE 都提供了不同程度的集成，因此使用起来相对简单；
目前主流 OS 的 Compiler 都能够不同程度上支持 Sanitizer，其通用性更强，因此对于需要跨平台的项目而言，它具备很大的优势；
相比同类工具，可用性更强，成本更低；
能力更强，能够检测的错误类型较多，诊断信息非常准确，能够帮助快速定位问题。

主流编译器对 Sanitizers 的支持情况

目前主流编译器都在一定程度上支持 Sanitizers，本节整理了 clang、GCC、MSVC 这三款主流编译器对 Sanitizers 的支持情况。

LLVM clang

Google 工程师最初在 LLVM clang上实现了 Sanitizers，LLVM clang 对各种 Sanitizer 支持非常全面，具体可以参见 LLVM clang 的官方文档：

链接1.png

Apple clang

需要注意的是，Apple clang 是基于 LLVM clang 但是不是完全照搬 LLVM clang，两者是存在区别的。目前 Apple clang 不支持 lsan，支持其它几种 Sanitizer，macOS 的 Instruments 工具提供了检测 Memory leakage 的能力。
MSVC

目前 MSVC 仅支持 asan，不支持检测 use-after-return 类错误，从实践来看，MSVC 在开启 asan 后，在一些特定情况下会出现比较奇怪的问题，用户可以考虑设计编译器版本。

更多内容参见:

github.com/google/sani…
GCC

从实践和 GCC 支持的编译选项来看，GCC 不支持 msan，支持其它几种 Sanitizer。

更多内容参见:

gcc.gnu.org/onlinedocs/…