[cfe-dev] __asan_memcpy insuppressible

Wed Jan 31 16:35:24 PST 2018

I just posted my question to SO https://stackoverflow.com/questions/48553654/is-asan-memcpy-insuppressible-by-design-or-by-accident, in case anyone wants to answer it there. Is __asan_memcpy insuppressible by design or by accident?

Mike Pozulp
pozulp1 at llnl.gov
925-422-0653
________________________________
From: Pozulp, Michael Mettler
Sent: Friday, January 26, 2018 5:40:18 PM
To: cfe-dev at lists.llvm.org
Cc: Ahn, Dong H.; Dawson, Shawn A.; Earl, Chris
Subject: __asan_memcpy insuppressible

Hello!

I'm a brand new clang user and this is my first time on the cfe-dev mailing list. I was wondering if anyone could tell me what I'm doing wrong.

I'm running clang 4.0.0 asan built on Linux x86_64. I built my code using clang++ -fsanitize=address.

I can't suppress the following memory issue reported by asan outside my code: (I have abridged the stack trace and modified some filepaths)

==104630==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200019367c at pc 0x2aaaaadc0d85 bp 0x7fffffff7e90 sp 0x7fffffff7640
READ of size 16 at 0x60200019367c thread T0
    #0 0x2aaaaadc0d84 in __asan_memcpy /path/to/llvm-4.0.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453
    #1 0x5b74a8 in _ZNSt3__116allocator_traitsINS_9allocatorIiEEE20__construct_backwardIiEENS_9enable_ifIXaaoosr7is_sameIS2_NS1_IT_EEEE5valuentsr15__has_constructIS2_PS6_S6_EE5valuesr31is_trivially_move_constructibleIS6_EE5valueEvE4typeERS2_S8_S8_RS8_ /path/to/clang/clang-4.0.0/rawbin/../include/c++/v1/memory:1676:17
    #2 0x5b74a8 in std::__1::vector<int, std::__1::allocator<int> >::__swap_out_circular_buffer(std::__1::__split_buffer<int, std::__1::allocator<int>&>&) /path/to/clang/clang-4.0.0/rawbin/../include/c++/v1/vector:886
    #3 0x5b648a in void std::__1::vector<int, std::__1::allocator<int> >::__push_back_slow_path<int const&>(int const&) /path/to/clang/clang-4.0.0/rawbin/../include/c++/v1/vector:1574:5
    #4 0x1d8d2ba in std::__1::vector<int, std::__1::allocator<int> >::push_back(int const&) /path/to/clang/clang-4.0.0/rawbin/../include/c++/v1/vector:1591:9
    #5 0x1d8d2ba in bar::baz(a_type const*, int const*, std::__1::vector<int, std::__1::allocator<int> >&) /path/to/installed/3rd/party/library/that/i/did/not/build/foo.cc:394

I am following the instructions here http://releases.llvm.org/4.0.0/tools/clang/docs/AddressSanitizer.html#issue-suppression , and I verified that my .supp is being read by typing gibberish in it and seeing "AddressSanitizer: failed to parse suppressions" printed to my terminal. I took a look at the src for __asan_memcpy in compiler-rt-4.0.0.src/lib/asan/asan_interceptors.cc

452 void *__asan_memcpy(void *to, const void *from, uptr size) {
453   ASAN_MEMCPY_IMPL(nullptr, to, from, size);
454 }

I think the "nullptr" is my problem. I followed the macro trail to find these lines

 68       AsanInterceptorContext *_ctx = (AsanInterceptorContext *)ctx;     \

 69       bool suppressed = false;                                          \
 70       if (_ctx) {                                                       \
 71         suppressed = IsInterceptorSuppressed(_ctx->interceptor_name);   \
 72         if (!suppressed && HaveStackTraceBasedSuppressions()) {         \
 73           GET_STACK_TRACE_FATAL_HERE;                                   \
 74           suppressed = IsStackTraceSuppressed(&stack);                  \
 75         }                                                               \
 76       }                                                                 \
 77       if (!suppressed) {                                                \
 78         GET_CURRENT_PC_BP_SP;                                           \
 79         ReportGenericError(pc, bp, sp, __bad, isWrite, __size, 0, false);\
 80       }

Since ctx is always "nullptr", "if (_ctx)" always evaluates to false, meaning I will not be able to suppress my memory error. Is this by design, or by mistake?

A quick look at the latest compiler-rt src that I pulled down today (git hash 286b899df64bb82a2da253114653adaf15da2fce, git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@323510 91177308-0d34-0410-b5e6-96231b3b80d8) shows the same situation exists for the latest asan implementation, so I don't think that updating to the latest asan rtl will help.

Mike Pozulp
pozulp1 at llnl.gov
925-422-0653
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180201/1f963cb6/attachment.html>