尝试AddressSanitizer的allow_user_poisoning时__asan_poison_memory_region失效

看起来你在测试ASAN的用户自定义内存poison特性时遇到了问题——明明调用了__asan_poison_memory_region，但写入被标记的内存却没触发预期的ASAN报错。结合你的代码和日志，我整理了几个最可能的原因和排查步骤：

1. 编译时必须显式开启allow_user_poisoning #

AddressSanitizer的用户内存poison功能默认是关闭的，你必须在编译阶段添加专门的编译选项才能启用它：
对于GCC：

gcc -fsanitize=address -fsanitize-address-allow-user-poisoning your_code.c -o test

对于Clang：

clang -fsanitize=address -fsanitize-address-allow-user-poisoning your_code.c -o test

如果没加这个选项，__asan_poison_memory_region会被编译器替换为空函数，自然不会有任何效果。这是最常见的原因，优先检查这个！

2. 确认内存区域的对齐和粒度 #

ASAN的内存标记是按固定粒度工作的：64位系统是8字节，32位系统是4字节。如果你的内存区域起始地址或长度不符合这个粒度，可能会导致标记不完整。不过你的例子里用malloc(sizeof(int))，malloc返回的地址默认是对齐的，sizeof(int)也符合粒度要求，这个大概率没问题，但可以加个打印验证：

printf("p address: %p, size: %zu\n", p, sizeof(int));

确保地址的最后几位（64位看最后3位，32位看最后2位）是0。

3. 检查ASAN版本和运行环境 #

旧版本的GCC/Clang（比如GCC 8及以下）对allow_user_poisoning的支持可能有bug，建议升级到GCC 9+或Clang 10+试试。另外，运行时的ASAN_OPTIONS环境变量可能有干扰，你可以清空它再运行：

ASAN_OPTIONS= ./test

4. 用更明确的测试代码验证 #

修改你的测试代码，加入unpoison操作，对比两种情况的行为：

#include <stdlib.h>
#include <stdio.h>
void __asan_poison_memory_region(void *p, int n);
void __asan_unpoison_memory_region(void *p, int n);

void unit_test_2(void) {
    int *p = (int *)malloc(sizeof(int));
    // 标记内存为有毒
    __asan_poison_memory_region(p, sizeof(int));
    
    // 这里写入应该触发ASAN报错
    *p = 1;
    printf("%p:%d\n", p, *p);
    
    // 解除标记
    __asan_unpoison_memory_region(p, sizeof(int));
    // 这里写入应该正常
    *p = 2;
    printf("%p:%d\n", p, *p);
    
    free(p);
}

int main() {
    unit_test_2();
    return 0;
}

如果编译时加了正确的选项，运行后第一个写入操作应该立刻触发ASAN的崩溃报错，显示内存访问越界（有毒内存）。

5. 查看详细的ASAN初始化日志 #

运行程序时开启ASAN的详细日志，确认user poisoning是否被启用：

ASAN_OPTIONS=verbosity=2 ./test

在初始化日志里找类似allow_user_poisoning=true的条目，如果找不到，说明编译选项确实没加对。

内容的提问来源于stack exchange，提问作者user14944