5

我正在尝试让地址清洁剂黑名单在 C++ 项目中工作，但它没有按预期工作。我在他们的网站上试过这个例子，如果我用 编译clang，它工作正常。

build % cat suppress.txt
fun:bad_foo

build % cat foo.c
#include <stdlib.h>
void bad_foo() {
  int *a = (int*)malloc(40);
  a[10] = 1;
}
int main() { bad_foo(); }

build % clang -fsanitize=address -fsanitize-blacklist=suppress.txt foo.c ; ./a.out
Exit code: 0

但是一旦我使用clang++它，它就会被忽略。

build % cp foo.c foo.cpp
build % clang++ -fsanitize=address -fsanitize-blacklist=suppress.txt foo.cpp ; ./a.out
=================================================================
==9943==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000003f8 at pc 0x00010ff93ee8 bp 0x7ffedfc6c340 sp 0x7ffedfc6c338
WRITE of size 4 at 0x6040000003f8 thread T0
Provided dSYM: [/Users/.../build/./a.out.dSYM/Contents/Resources/DWARF/a.out] does not match symbol owner 0x7fe1b060edc0
    #0 0x10ff93ee7 in bad_foo() (a.out:x86_64+0x100000ee7)
    #1 0x10ff93f08 in main (a.out:x86_64+0x100000f08)
    #2 0x7fff7940508c in start (libdyld.dylib:x86_64+0x1708c)

0x6040000003f8 is located 0 bytes to the right of 40-byte region [0x6040000003d0,0x6040000003f8)
allocated by thread T0 here:
    #0 0x10fff2173 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5c173)
    #1 0x10ff93e93 in bad_foo() (a.out:x86_64+0x100000e93)
    #2 0x10ff93f08 in main (a.out:x86_64+0x100000f08)
    #3 0x7fff7940508c in start (libdyld.dylib:x86_64+0x1708c)

SUMMARY: AddressSanitizer: heap-buffer-overflow (a.out:x86_64+0x100000ee7) in bad_foo()
Shadow bytes around the buggy address:
  0x1c0800000020: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 05
  0x1c0800000030: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 05
  0x1c0800000040: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 07
  0x1c0800000050: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x1c0800000060: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
=>0x1c0800000070: fa fa 00 00 00 00 00 05 fa fa 00 00 00 00 00[fa]
  0x1c0800000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0800000090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c08000000c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==9943==ABORTING
[1]    9943 abort      ./a.out
Exit code: 134

我正在使用来自 release.llvm.org 的 clang-7

build % clang --version
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Users/.../clang+llvm-7.0.0-x86_64-apple-darwin/bin

这在 C++ 下不支持吗？

4

1 回答 1

3

在 C++中，函数名称将被损坏，看起来黑名单要求我们使用损坏的名称，例如：

fun:_Z7bad_foov

那么它将对我有用。我们可以从我认为您正在使用的示例中看到他们也有一个使用错误名称的示例，但他们没有解释：

# Turn off checks for a particular functions (use mangled names):
fun:MyFooBar
fun:_Z8MyFooBarv

您可以使用类似nm的实用程序来查找损坏的名称，例如，当我这样做时，您的示例：

nm a.out

我看到这样的事情：

0000000100000e80 T __Z7bad_foov
...

不知道为什么我们会获得额外的_，但我们确实做到了。

于 2018-11-30T05:08:33.117 回答