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

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

我正在尝试编写一个小而简单的协程库，只是为了更深入地了解 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 报告使用后作用域（godbolt 提供完整输出，上面的链接）。在 lldb 的帮助下，我发现错误是在 main 中抛出的，更准确地说：在汇编列表中第 112 行的跳转，jne .LBB2_15，跳转到 asan 的报告并且永不返回。它似乎在 main 的序言中。

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

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

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

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

希望答案对我有帮助

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

提前致谢。

¹ 这最初让我相信 clang 的优化器正在直接从（被破坏的）协程的框架中读取 result，但是将 destroy() 移入任务的析构函数将问题带回来并证明该理论是错误的，据我所知。 destroy() 不在上面清单中的析构函数中，因为它需要实现移动构造/赋值以避免双重释放，我希望示例尽可能小而清晰。

解决方法

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

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

Value

clang-11 有，clang-12 没有。从它的外观来看，地址清理器尝试在初始化之前检查 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,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（它应该是 promise 的清理方法）是否已初始化。 Clang-12 只对 promise 不执行任何检查，而忽略了上面代码的整体性。

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

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

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

解决方法

相关推荐