使用地址清理器时，协程框架似乎被过早标记为已销毁

Question

我正在尝试编写一个小而简单的协程库，只是为了更深入地了解 C++20 协程。它似乎工作正常，但是当我用 clang 的地址消毒器编译时，它向我抛出。

我已将问题缩小到以下代码示例（可在 https://godbolt.org/z/WqY6Gd 获得编译器和消毒器输出），但我仍然无法理解它。

// 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 报告 use-after-scope（完整输出可在 godbolt 获得，link 以上）。在 lldb 的帮助下，我发现错误是在 main 中抛出的，更准确地说：程序集列表中第 112 行的跳转，jne .LBB2_15，跳转到 asan 的报告，而不是 returns。好像是在main的序幕里面。

如评论所示，将 destroy() 下移一行或在单独的 noinline 函数中调用它 ¹ 会更改地址清理程序的行为。对此仅有的两种解释似乎是未定义的行为和 asan 抛出误报（或者 -fsanitize=address 本身正在造成生命周期问题，这在某种意义上是相同的）。

此时我相当确定上面的代码中没有 UB：task 和 result 都存在于 main 的堆栈框架中，promise 对象存在于协程框架中。帧本身在 main 的第 1 行分配（在 main 的堆栈上，因为没有挂起点），并在返回之前销毁，超过了 foo() 中对其的最后一次访问。协程框架不会自动销毁，因为根据 the standard，控制永远不会流出 co_await final_suspend()。不过，我已经盯着这段代码看了一段时间，所以如果我遗漏了一些明显的东西，请原谅我。

在没有清理的情况下生成的程序集对我来说似乎很有意义，所有内存访问都发生在分配的 [rsp, rsp+24] 内。此外，使用 -fsanitize=address,undefined 或仅 -fsanitize=undefined 进行编译，或仅使用 -fsanitize=address 进行 gcc 编译都不会报告任何错误，这让我相信问题隐藏在 asan 生成的代码中的某处。

不幸的是，我无法完全理解 asan 检测的代码中到底发生了什么，这就是我发布此内容的原因。我对 Address sanitizer's algorithm 有一个大致的了解，但我无法将程序集内存 access/allocations 映射到 C 中发生的事情 ++代码。

我希望答案对我有所帮助

了解生命周期问题隐藏在哪里，如果有的话
了解使用 asan 编译时 main 中到底发生了什么，以便阅读本文的人可以更清楚地找到 C++ 代码中的哪些内存访问触发了错误，以及在哪里（如果有的话） ) 是分配和释放的内存。
始终抑制这种特殊的误报，并详细说明导致它的原因，如果问题确实出在 asan 中。

提前致谢。

¹ 这最初让我相信 clang 的优化器正在直接从（已销毁的）协同程序的框架中读取 result，但是将 destroy() 移动到任务的据我所知，析构函数将问题带回来并证明该理论是错误的。 destroy() 不在上面清单的析构函数中，因为它需要执行 move construction/assignment 以避免双重释放，我希望示例尽可能小和清晰。

Answer 1

我想我明白了 - 但主要是因为它已经在 clang12.0 中修复了。

运行带有 clang-12 的 smaller/cleaner example 没有显示来自 asan 的错误。区别在于以下几行：

    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

clang-11有，clang-12没有。从外观上看，地址消毒程序会在初始化之前尝试检查 r12+40（应该是 promise 的清理方法）是否已初始化。 Clang-12 不对 promise 执行任何检查，将上面代码的完整性留在外面。

TL;DR：（可能）clang-11 协程卫生中的一个错误，已在 12.0 中修复，也许在更高版本的 clang-11 中也是如此。

使用地址清理器时，协程框架似乎被过早标记为已销毁

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

c++

c++20

address-sanitizer

c++-coroutine