CODEWITHSUNDEEP
c++c++20address-sanitizerc++-coroutine
ARentalTV
ARentalTV

Reputation: 376

Coroutine frame seems to be prematurely marked as destroyed when using address sanitizer

I am trying to write a small and simple coroutine library just to get a more solid understanding of C++20 coroutines. It seems to work fine, but when I compile with clang's adress sanitizer, it throws up on me.

I have narrowed down the issue to the following code example (available with compiler and sanitizer output at https://godbolt.org/z/WqY6Gd), but I still can't make any sense of it.

// namespace coro = std::/std::experimental;

// inlining this suppresses the error
__attribute__((noinline)) void foo(int& i) { i = 0; }

struct task {
  struct promise_type {
    promise_type() = default;
    coro::suspend_always initial_suspend() noexcept { return {}; }
    coro::suspend_always final_suspend() noexcept { return {}; }
    void unhandled_exception() noexcept { std::terminate(); }
    void return_value(int v) noexcept { value = v; }
    task get_return_object() {
      return task{coro::coroutine_handle<promise_type>::from_promise(*this)};
    }
    int value{};
  };

  void Start() { return handle_.resume(); }
  int Get() {
    auto& promise = handle_.promise();
    return promise.value;
  }

  coro::coroutine_handle<promise_type> handle_;
};

task func() { co_return 3; }

int main() {
  auto t = func();
  t.Start();
  const auto result = t.Get();
  foo(t.handle_.promise().value);
  // moving this one line down or separating this into a noinline 
  // function suppresses the error
  // removing this removes the stack-use-after-scope, but (rightfully) reports a leak
  t.handle_.destroy();
  if (result != 3) return 1;
}

Address sanitizer reports use-after-scope (full output available at godbolt, link above). With some help from lldb, I found out that the error is thrown in main, more precisely: the jump at line 112 in the assembly listing, jne .LBB2_15, jumps to asan's report and never returns. It seems to be inside main's prologue.

As the comments indicate, moving destroy() a line down or calling it in a separate noinline function1 changes the behavior of address sanitizer. The only two explanations to this seem to be undefined behavior and asan throwing a false positive (or -fsanitize=address itself is creating lifetime issues, which is sort of the same in a sense).

At this point I'm fairly certain that there's no UB in the code above: both task and result live on main's stack frame, the promise object lives in the coroutine frame. The frame itself is allocated (on main's stack because no suspend-points) at line 1 of main, and destroyed right before returning, past the last access to it in foo(). The coroutine frame is not destroyed automatically because control never flows off co_await final_suspend(), as per the standard. I've been staring at this code for a while, though, so please forgive me if I missed something obvious.

The assembly generated without sanitation seems to makes sense to me and all the memory access happens within [rsp, rsp+24], as allocated. Futhermore, compiling with -fsanitize=address,undefined, or just -fsanitize=undefined, or simply compiling with gcc with -fsanitize=address reports no errors, which leads me to believe the issue is hidden somewhere in the code generated by asan.

Unfortunately, I can't quite make sense of what exactly happens in the code instrumented by asan, and that's why I'm posting this. I have a general understanding of Address sanitizer's algorithm, but I can't map the assembly memory access/allocations to what's happenning in the C ++ code.

I'm hoping that an answer will help me

  1. Understand where the lifetime issues are hidden, if there are any
  2. Understand what exactly happens in main when compiled with asan, so that a person reading this can have a more clear way of finding what memory access in the C++ code triggered the error, and where (if anywhere) was that memory allocated and freed.
  3. Consistently suppress this particular false positive, and elaborate a bit on what causes it, if the issue really is in asan.

Thanks in advance.

1 This initially lead me to believe that clang's optimizer is reading result from the (destroyed) coroutine's frame directly, but moving destroy() into task's destructor brings the issue back and proves that theory wrong, as far as I can tell. destroy() is not in the destructor in the listing above because it requires implementing move construction/assignment in order to avoid double free, and I wanted to keep the example as small and clear as possible.

Upvotes: 1

Views: 627

Answers (1)

ARentalTV
ARentalTV

Reputation: 376

I think I figured it out - but mostly because it's already fixed in clang12.0.

Running the smaller/cleaner example with clang-12 shows no error from asan. The difference is in the following lines:

    movabs  rcx, -866669180174077455    
    mov     qword ptr [r13 + 2147450880], rcx   
    mov     dword ptr [r13 + 2147450888], -202116109    
    lea     rdi, [r12 + 40] 
    mov     rcx, rdi    
    shr     rcx, 3  
    cmp     byte ptr [rcx + 2147450880], 0  
    jne     .LBB2_14    
    lea     r14, [r12 + 32] 
    mov     qword ptr [r14 + 8], offset f() [clone .cleanup]    
    lea     rdi, [r14 + 16] 
    mov     byte ptr [r13 + 2147450884], 0  
    mov     rcx, rdi    
    shr     rcx, 3  
    mov     dl, byte ptr [rcx + 2147450880] 
    test    dl, dl  
    jne     .LBB2_7 
.LBB2_8:    
    mov     qword ptr [rbx + 16], rax       # 8-byte Spill  
    mov     dword ptr [r14 + 16], 0

Which clang-11 has, and clang-12 doesn't. From the looks of it, the address sanitizer tries to check that r12+40 (which should be the promise's cleanup method) is initialized before initializing it. Clang-12 just performs no checks for the promise, leaving the entirity of the code above out.

TL;DR: (probably) a bug in clang-11 coroutine sanitation, fixed in 12.0, perhaps in later versions of clang-11 as well.

Upvotes: 0

Related Questions