导读： 非法的内存访问是最最常见的一种内存错误，本文介绍用于检测这类错误的 Sanitizer：AddressSanitizer（简称 asan）。
二分查找算法是非常经典的算法，它看似简单，但是写出一个完全正确的二分查找算法还是比较考验工程师的算法功力的，下面是在网上流传的一个版本，请读者思考：这个程序正确吗？
#include
#include
size_t binary_search(std::vector &nums, int target)
{
size_t left = 0, right = nums.size();
while (left < right)
{
size_t mid = left + (right - left - 1) / 2;
if (nums[mid] == target)
{
return mid;
}
else if (nums[mid] < target)
{
left = mid + 1;
}
else
{
right = mid;
}
}
return nums[left] == target ? left : -1;
}
int main()
{
std::vector a = {2};
int target = 3;
std::cout << binary_search(a, target) << std::endl;
}
运行上述程序后输出 -1，显然是符合预期的，那这是否就说明这个程序是完全正确呢？
答案是：这个程序是存在错误的。 那错在哪一句呢？读者可以通过分析发现问题所在，在这里我们尝试使用 asan 工具来定位问题，完整程序在:
https://github.com/dengking/sanitizers/tree/main/asan/examples/heap-buffer-overflow/binary-search-example
其中记录了在不同 OS 上的运行情况。运行程序，可以看到如下输出：
==13564==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x000104e00734 at pc 0x000102a1894c bp 0x00016d3eae60 sp 0x00016d3eae58
READ of size 4 at 0x000104e00734 thread T0
#0 0x102a18948 in binary_search(std::__1::vector >&, int) test.cc:34
#1 0x102a18cf4 in main test.cc:23
#2 0x102c5d084 in start+0x200 (dyld:arm64e+0x5084)
通过上述输出我们知道在 test.cc 的 23 行发生了 heap-buffer-overflow，准确地说就是下面这句：
nums[left] == target通过上述小例子， 展示了 asan 的作用：严格地对程序中的内存访问进行检查，一旦发现访问了不该访问的内存区域，立即汇报准确的错误信息并终止程序，而不是在错误的基础上继续运行导致当程序异常退出时最终表现出的现象非常扑朔迷离，能够帮助工程师快速地定位到程序中与内存相关的 bug。
asan 是在 Google 研发团队于 2011 年发表的论文 AddressSanitizer: A Fast Address Sanity Checker 中提出的，并在 LLVM clang 中实现。论文中对 asan 的优势总结为：
AddressSanitizer achieves efficiency without sacrificing comprehensiveness. Its average slowdown is just73% yet it accurately detects bugs at the point of occurrence.
总的来说，asan 的优势：
asan 的核心功能是检测内存访问错误 ，简单地说就是如果发现程序访问了不该访问的内存，asan 能够及时报告详细的错误信息。更加具体地说：asan 能够发现对 heap object、stack object、global object 的 out-of-bounds access（越界访问）、use-after-free（dangling）等 bug。除了 内存访问错误 ，asan 还能检测出一些其它内存错误，比如 Static Initialization Order Fiasco 。为了便于读者学习，下面结合 example code 来展示 asan 能够检测的错误。
asan 提供了丰富的 flag 供工程师决定开启或关闭对某种内存错误的检测，这将在 AddressSanitizerFlags 章节进行介绍。
非法内存访问的 example code
下面结合具体的例子来描述asan的能力，这些例子展示了一些典型的memory error，这些例子主要来自于：
为便于工程师学习使用，我对上述文章中的例子进行了一些调整：
需要注意的是 :
example code | 链接 |
stack-buffer-oveflow | |
sbo_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-buffer-overflow/sbo_c.c |
sbo_down_cast.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-buffer-overflow/sbo_down_cast.cc |
stack-buffer-underflow | |
sbu_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-buffer-underflow/sbu_c.c |
sbu_cpp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-buffer-underflow/sbu_c.c |
heap-buffer-overflow | |
hbo_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/heap-buffer-overflow/hbo_c.c |
hbo_strncpy.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/heap-buffer-overflow/hbo_strncpy.c |
hbo_down_cast.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/heap-buffer-overflow/hbo_down_cast.cc |
global-buffer-overflow | |
gbo_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/global-buffer-overflow/c/gbo_c.c |
gbo_cpp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/global-buffer-overflow/cc/gbo_cpp.cc |
calloc-overflow | |
co.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/calloc-overflow/co.c |
导致进程访问了不属于自己的内存的原因还包括野指针等，因此由 Dangling 引发的内存错误排查的难度较大。对于这类错误，asan 能够及时发现进而在问题刚刚出现的时候就提示工程师，能够极大地减少排查的时间。
example code | 链接 |
heap-use-after-free | |
uaf_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/heap-use-after-free/uaf_c.c |
uaf_cpp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/heap-use-after-free/uaf_cpp.cc |
stack-use-after-return | |
uar_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-return/uar_c.c |
uar_cpp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-return/uar_cpp.cc |
stack-use-after-scope | |
uas_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-scope/uas_c.c |
uas_cpp_1.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-scope/uas_cpp_1.cc |
uas_cpp_2.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-scope/uas_cpp_2.cc |
uas_cpp_3.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/stack-use-after-scope/uas_cpp_3.cc |
example code | 链接 |
wp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/wild-pointer/wp.cc |
example code | 链接 |
df_c.c | https://github.com/dengking/sanitizers/blob/main/asan/examples/double-free/df_c.c |
df_cpp.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/double-free/df_cpp.cc |
example code | 链接 |
memcpy-param-overlap | |
mpo.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/memcpy-param-overlap/mpo.cc |
strncat-param-overlap | |
spo,cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/strncat-param-overlap/spo.cc |
example code | run-time flag | 链接 |
invalid-pointer-pairs | detect_invalid_pointer_pairs | https://github.com/dengking/sanitizers/tree/main/asan/examples/invalid-pointer-pairs |
example code | run-time flag | 链接 |
strict-string-check | strict_string_checks | https://github.com/dengking/sanitizers/tree/main/asan/examples/strict-string-check |
example code | 链接 |
deallocation-of-nonallocated-memory | https://github.com/dengking/sanitizers/tree/main/asan/examples/deallocation-of-nonallocated-memory |
Static Initialization Order Fiasco
asan 的 initialization-order checker， 主要是为了帮助工程师发现 Static Initialization Order Fiasco 问题。Static Initialization Order Fiasco 问题的根源在于 C++ 标准对于不同 translation unit 中具备 static storage duration 的 static object 的 dynamic initialization 的相对顺序无法进行统一定义，从而导致当位于不同的 translation unit 中的 static object 的 dynamic initialization 存在依赖关系时，可能会读取到未初始化的内存，进而导致程序错误，更多关于 Static Initialization Order Fiasco 的内容可以参见:
为了检测初始化顺序问题，asan 会在已编译的程序中插入“ checker ”。asan 的 initialization-order checker 默认是关闭的，通过传递运行时标志（ run-time flag ）来启用它们。asan 的 initialization-order checker 支持如下两种模式:
含义 | run-time flag | |
Loose init-order checking | 假设 static object A 的 dynamic initialization 依赖于位于另外一个 translation unit 中的 static object B，如果 static object B 还未初始化，那么 asan 将报错。 | check_initialization_order |
Strict init-order checking | 假设 static object A 的 dynamic initialization 依赖于位于另外一个 translation unit 中的 static object B，那么 asan 将报错。 | strict_init_order |
显然，“Loose init-order checking”在实际发生错误的情况下会及时报告错误，而“Strict init-order checking”则只要发现存在依赖关系，不管实际运行时是否会出现错误，都会报错。
在官方文档
（https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco）
Mismatch
example code | run-time flag | 链接 |
alloc-dealloc-mismatch | alloc_dealloc_mismatch | |
adm.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/alloc-dealloc-mismatch/adm.cc | |
new-delete-type-mismatch | new_delete_type_mismatch | |
ndtm.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/new-delete-type-mismatch/ndtm.cc |
std::vector 是 C++ 工程师最常使用的容器之一，在笔者的 GitHub 仓库 sanitizers/STL 中有关于 std::vector 的总结。
官方文档：
https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow
本节内容需要对 std::vector 的实现原理有一定了解。
给定 std::vector
下面是展示这种错误的 example code:
example code | 链接 |
container-overflow.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/container-overflow/container-overflow.cc |
container-overflow2.cc | https://github.com/dengking/sanitizers/blob/main/asan/examples/container-overflow/container-overflow2.cc |
由于不同的 STL 对 container 的实现是不同的，因此相同的程序由不同的编译器生成的可执行文件运行时报出的错误可能不同。
asan 对它的检测有赖于对 std::vector 进行特殊实现，一般使用“code annotation”来帮助发现这种错误，如果没有这样做，那么 asan 可能无法发现这种错误。
需要注意的是有时候虽然 asan 会报“AddressSanitizer: container-overflow”这种错误，但是实际上它可能并不会导致程序异常，工程师可以通过如下方式来关闭这种检查从而关闭这种错误:
方式一: 对触发错误的函数关闭检查，这在“ 让asan关闭检查 ”章节进行了介绍。
方式二: 通过运行时标志 detect_container_overflow 全局关闭这种检查，asan 支持如下两种方式来传递运行时标志:
ASAN_OPTIONS=detect_container_overflow=0 在 AddressSanitizerFlags 章节对 ASAN_OPTIONS 进行了介绍。
const char*__asan_default_options()
{
return "detect_container_overflow=0";
}
完整例子:
https://github.com/dengking/sanitizers/blob/main/asan/examples/asan-default-options/detect_container_overflow.cc 。
Access outside of object lifetime in multi-thread application
C++ 标准对 object lifetime 进行了规范，并明确指出 access outside of lifetime 是错误的，通过 cppreference Storage duration 中的内容可知，每个 C++ object 都对应一片内存区域，这提示我们前面提到的很多内存访问错误都属于“access outside of lifetime”范畴。
在实际开发过程中，更容易发生 access outside of lifetime 的情况是在多线程程序中，由于篇幅有限，关于这个 topic 的内容可以参见笔者的笔记:
主题 | 链接 |
Access-outside-of-object-lifetime | https://github.com/dengking/programming-language/blob/master/docs/C%2B%2B/CppRef/Basic-concept/Object/Lifetime%26storage-duration/Access-outside-of-object-lifetime/index.md |
Access outside of object lifetime in multi-thread application | https://github.com/dengking/programming-language/blob/master/docs/C%2B%2B/CppRef/Basic-concept/Object/Lifetime%26storage-duration/Access-outside-of-object-lifetime/Multi-thread%26observer-pattern/index.md |
Pure-virtual-method-called | https://github.com/dengking/programming-language/blob/master/docs/C%2B%2B/CppRef/Basic-concept/Object/Lifetime%26storage-duration/Access-outside-of-object-lifetime/Pure-virtual-method-called/index.md |
cmake-based-project
下面两种方式各有优劣，适合于不同的工程:
第一种：
set (CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
set (CMAKE_LINKER_FLAGS_DEBUG "${CMAKE_LINKER_FLAGS_DEBUG} -fno-omit-frame-pointer -fsanitize=address")
二、arsenm/sanitizers-cmake
项目链接: https://github.com/arsenm/sanitizers-cmake
优势: sanitizers-cmake 是一个 cmake package，它使用起来比较方便，能够帮助 cmake-based project 快速地开启各种 sanitizers，目前在 litesdk 中已经尝试使用了。
劣势:
IDE
参考:
https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/
参考:
https://developer.apple.com/documentation/xcode/diagnosing-memory-thread-and-crash-issues-early
官方文档:
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags
asan 提供了丰富的 flag 来供使用者对它进行灵活的调整。
Compiler flags
flag | description |
-fsanitize=address | 开启 AddressSanitizer |
-fno-omit-frame-pointer | 保留 frame pointers，保证 unwinder 快速地展开函数调用堆栈 |
-fsanitize-blacklist=path | 指定 blacklist file，这在 让 asan 关闭检查 章节进行专门介绍 |
-fsanitize-recover=address | 在 Continue after error mode 章节进行专门介绍 |
Run-time flags
Sanitizers 的 run-time flag 非常多，它可以分为两大类:
设置 flag 的两种方式
asan 支持如下两种方式来传递 run-time flags，工程师可以根据实际情况选取合适的方式。
使用该函数来将 run-time flags 嵌入代码中，例子:
https://github.com/dengking/sanitizers/tree/main/asan/examples/asan-default-options
查看完整的 run-time flag
以 macOS 为例，可以通过如下方式来查看 asan 实际支持的完整的 run-time flag:
ASAN_OPTIONS=help=1 ./a.out例子:
https://github.com/dengking/sanitizers/tree/main/asan/examples/run-time-flags
开启/关闭 asan能力的flag
asan 的一些能力可以通过 run-time flags 来开启/关闭，本节对此进行总结:
Flag | Default value | usage | example |
report_globals | 1 | 控制处理global object的方式 （0 - 不检测 global object 的 buffer overflow 错误； 1 - 检测global object的buffer overflow错误； 2 - print data about registered globals） | global-buffer-overflow |
detect_stack_use_after_return | false | 在运行时启用 stack-use-after-return 错误检查 | stack-use-after-return |
detect_container_overflow | true | 开启检测容器溢出注解。参见：https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow | container-overflow |
check_initialization_order | false | 开启检测 initialization order 问题 | initialization-order-checker |
strict_init_order | false | initialization-order-checker | |
alloc_dealloc_mismatch | true （false on Darwin and Windows） | 检测malloc/delete, new/free, new/delete[], 等 | alloc-dealloc-mismatch |
new_delete_type_mismatch | true | 检测 new 和 delete 对象的大小不匹配 | new-delete-type-mismatch |
strict_string_checks | false | 检测 string 是 null-terminated 的 | strict-string-check |
detect_invalid_pointer_pairs | 0 | If non-zero, try to detect operations like <, <=, >, >= and - on invalid pointer pairs (e.g. when pointers belong to different objects). The bigger the value the harder we try | invalid-pointer-pairs |
出于如下原因想让 asan 不检查特定函数：
目前 asan 提供了两种方式来指定不检查指定函数:
function attribute
使用 C++ 语言的 function attribute 语法特性，完整例子:
https://github.com/dengking/sanitizers/tree/main/asan/examples/turning-off-instrumentation 。
在 https://github.com/dengking/sanitizers/blob/main/asan/examples/turning-off-instrumentation/attribute/no_sanitize_address_attribute.h 中，给出了跨平台的写法。
从目前的实践来看，clang、GCC、MSVC 都支持这种方式。
attribute | |
__attribute__((no_sanitize_address)) | 已经被弃用 |
__attribute__((no_sanitize("address"))) | 能够正常使用；关闭 asan |
__attribute__((disable_sanitizer_instrumentation)) | since clang 15 关闭所有的 Sanitizer，不仅仅 asan |
__declspec(no_sanitize_address)compiler flag: sanitize-blacklist、sanitize-ignorelist
在github Turning off instrumentation
（https://github.com/google/sanitizers/wiki/AddressSanitizer#turning-off-instrumentation）
中，介绍的 compiler flag 是 Sanitize-blacklist，而在 clang Sanitizer special case list
（https://clang.llvm.org/docs/SanitizerSpecialCaseList.html）
中介绍的 compiler flag 是 Sanitize-ignorelist，从实践来看，两者的功能类似，以 clang Sanitizer special case list 为准，使用 Sanitize-ignorelist。
下面是 ignorelist 文件的例子:
# Lines starting with # are ignored.
# Turn off checks for the source file (use absolute path or path relative
# to the current working directory):
src:/path/to/source/file.c
# Turn off checks for a particular functions (use mangled names):
fun:MyFooBar
fun:_Z8MyFooBarv
# Extended regular expressions are supported:
fun:bad_(foo|bar)
src:bad_source[1-9].c
# Shell like usage of * is supported (* is treated as .*):
src:bad/sources/*
fun:*BadFunction*
# Specific sanitizer tools may introduce categories.
src:/special/path/*=special_sources
# Sections can be used to limit ignorelist entries to specific sanitizers
[address]
fun:*BadASanFunc*
# Section names are regular expressions
[cfi-vcall|cfi-icall]
fun:*BadCfiCall
# Entries without sections are placed into [*] and apply to all sanitizers
目前，MSVC、GCC 还不支持 Sanitize-ignorelist。
官方文档:
https://github.com/google/sanitizers/wiki/AddressSanitizerCallStack
asan 会收集以下事件的调用堆栈：
malloc 和 free 发生相对频繁，因此快速展开调用堆栈很重要，否则会影响性能。asan 使用一个简单的 unwinder 来展开调用堆栈，它依赖于帧指针。
如果不关心 malloc/free 调用堆栈，可以通过设置运行时标识 malloc_context_size=0 来完全禁用。
为了使错误信息能够包含源代码信息以便于工程师定位，每个栈帧都需要符号化（前提是二进制产物是以 debug 模式编译的），在符号化后，给定 PC 寄存器，asan 能够打印
#0xabcdf function_name file_name.cc:1234asan 对栈帧的符号化是依赖于 symbolizer 可执行程序，不同编译器的 symbolizer 可执行程序不同，比如 clang 使用 llvm-symbolizer。通常情况下，工程师的开发环境的编译器套件已经包含 symbolizer 并且能够正常调用，因此大多数情况下工程师是无需关注 symbolizer。
总的来说，asan 使用 unwinder 来展开调用堆栈，使用 symbolizer 来符号化堆栈。
asan 支持通过环境变量 ASAN_SYMBOLIZER_PATH 来指定 symbolizer 可执行程序，此时需要保证 symbolizer 可执行程序位于 PATH 环境变量中，如果出于某种原因要禁用符号化，可以通过提供空字符串作为 ASAN_SYMBOLIZER_PATH 值来实现，下面以 macOS 为例来说明:
ASAN_SYMBOLIZER_PATH= ./a.out读者可以使用 examples
（https://github.com/dengking/sanitizers/tree/main/asan/examples） 中的例子进行验证，对比禁用符号化前后的堆栈信息。
默认情况下，在发现错误后，asan 会立即让进程 crash，但 asan 支持更改这种默认行为让进程在发现错误后继续运行，这种模式被称为“continue after error mode”，要启用“continue after error mode”，需要使用 -fsanitize-recover=address 进行编译，运行时需要设置 ASAN_OPTIONS=halt_on_error=0
完整例子参见:
https://github.com/dengking/sanitizers/tree/main/asan/examples/continue-after-error
Chromium 工程实践
根据 Google 论文中的介绍, 自从 2011 年 5 月发布 asan 工具以来，开源浏览器 Chromium 已定期使用 asan 进行测试。在测试的前 10 个月中，该工具在 Chromium 代码和第三方库中检测到 300 多个以前未知的错误。210 个 bug 是 heap-use-after-free，73 个是 heap-buffer-overflow，8 个 global-buffer-overflow，7 个 stack-buffer-overflow 和 1 个 memcpy 参数重叠。在另外 13 种情况下，asan 触发了一些其他类型的程序错误（例如，未初始化的内存读取）。
Chromium 主要通过如下两种方法来发现 bug：
在上述任何一种情况下，开启 asan 后生成产物的运行速度都是至关重要的。对于单元测试，asan 的高性能优势允许使用更少的机器来跟上源代码的变化。对于 Fuzzing test，asan 的性能优势允许在几秒钟内运行随机测试，一旦发现错误，在合理的时间内最小化测试来准确定位问题。通过手动运行开启 asan 后生成的产物也发现了少量错误。
除了 Chromium，Google asan 团队还测试了大量其他代码，发现了很多错误。和 Chromium 一样，heap-use-after-free 是最常见的 bug。然而， stack-buffer-overflow 和 global-buffer-overflow 比 Chromium 更常见。在 LLVM 本身中检测到几个 heap-use-after-free 错误。Google asan 团队也收到了有关 asan 在 Firefox、Perl、Vim 和其他几个开源项目中发现的错误的通知。
| 留言与评论（共有 0 条评论） “” |
