1

我正在尝试在我的 docker 容器中设置/修复 asan。为此，我使用了一个简单的示例程序

int main() { return 16; }

并编译它

clang++ -std=c++1z -O1 -fsanitize=address test.cpp

使用 clang 4.0.1（我使用它没有区别-std）。

这会产生4.12.3-1-ARCH内核版本的错误，而我从谷歌或 asan FAQ 中提取的所有内容似乎都没有改变这一点。

$ ./a.out 
==13178==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==13178==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
==13178==Process memory map follows:
    0x00eda9b0a000-0x00eda9c4e000   /tmp/a.out
    0x00eda9e4e000-0x00eda9e4f000   /tmp/a.out
    0x00eda9e4f000-0x00eda9e52000   /tmp/a.out
    0x00eda9e52000-0x00edaab37000   
    0x7f4266de9000-0x7f426713b000   
    0x7f426713b000-0x7f42672d8000   /usr/lib/libc-2.25.so
    0x7f42672d8000-0x7f42674d7000   /usr/lib/libc-2.25.so
    0x7f42674d7000-0x7f42674db000   /usr/lib/libc-2.25.so
    0x7f42674db000-0x7f42674dd000   /usr/lib/libc-2.25.so
    0x7f42674dd000-0x7f42674e1000   
    0x7f42674e1000-0x7f42674f7000   /usr/lib/libgcc_s.so.1
    0x7f42674f7000-0x7f42676f6000   /usr/lib/libgcc_s.so.1
    0x7f42676f6000-0x7f42676f7000   /usr/lib/libgcc_s.so.1
    0x7f42676f7000-0x7f42676f8000   /usr/lib/libgcc_s.so.1
    0x7f42676f8000-0x7f42676fb000   /usr/lib/libdl-2.25.so
    0x7f42676fb000-0x7f42678fa000   /usr/lib/libdl-2.25.so
    0x7f42678fa000-0x7f42678fb000   /usr/lib/libdl-2.25.so
    0x7f42678fb000-0x7f42678fc000   /usr/lib/libdl-2.25.so
    0x7f42678fc000-0x7f4267903000   /usr/lib/librt-2.25.so
    0x7f4267903000-0x7f4267b02000   /usr/lib/librt-2.25.so
    0x7f4267b02000-0x7f4267b03000   /usr/lib/librt-2.25.so
    0x7f4267b03000-0x7f4267b04000   /usr/lib/librt-2.25.so
    0x7f4267b04000-0x7f4267b1d000   /usr/lib/libpthread-2.25.so
    0x7f4267b1d000-0x7f4267d1c000   /usr/lib/libpthread-2.25.so
    0x7f4267d1c000-0x7f4267d1d000   /usr/lib/libpthread-2.25.so
    0x7f4267d1d000-0x7f4267d1e000   /usr/lib/libpthread-2.25.so
    0x7f4267d1e000-0x7f4267d22000   
    0x7f4267d22000-0x7f4267e33000   /usr/lib/libm-2.25.so
    0x7f4267e33000-0x7f4268032000   /usr/lib/libm-2.25.so
    0x7f4268032000-0x7f4268033000   /usr/lib/libm-2.25.so
    0x7f4268033000-0x7f4268034000   /usr/lib/libm-2.25.so
    0x7f4268034000-0x7f42681ae000   /usr/lib/libstdc++.so.6.0.24
    0x7f42681ae000-0x7f42683ad000   /usr/lib/libstdc++.so.6.0.24
    0x7f42683ad000-0x7f42683b7000   /usr/lib/libstdc++.so.6.0.24
    0x7f42683b7000-0x7f42683b9000   /usr/lib/libstdc++.so.6.0.24
    0x7f42683b9000-0x7f42683bc000   
    0x7f42683bc000-0x7f42683df000   /usr/lib/ld-2.25.so
    0x7f42685b7000-0x7f42685c9000   
    0x7f42685cb000-0x7f42685da000   
    0x7f42685da000-0x7f42685df000   
    0x7f42685df000-0x7f42685e0000   /usr/lib/ld-2.25.so
    0x7f42685e0000-0x7f42685e1000   /usr/lib/ld-2.25.so
    0x7f42685e1000-0x7f42685e2000   
    0x7ffda4652000-0x7ffda4673000   [stack]
    0x7ffda46cc000-0x7ffda46cf000   [vvar]
    0x7ffda46cf000-0x7ffda46d1000   [vdso]
    0xffffffffff600000-0xffffffffff601000   [vsyscall]
==13178==End of process memory map.
4

2 回答 2

1

这可能是由于最近内核的变化改变了它加载 PIE 可执行文件的方式。上游正在讨论这个问题。

目前唯一的解决方法（除了使用较旧的内核）是使用以下之一重新编译

  • CFLAGS += -no-pie
  • CFLAGS += -mllvm -asan-force-dynamic-shadow=1（仅限叮当声）
于 2017-08-18T13:51:05.740 回答
0

这至少从内核版本开始就已修复4.12.10-1-ARCH。

（显然）较新的编译器版本也可以工作，但我没有亲自测试过。

于 2017-09-13T12:49:46.327 回答