destructors not always properly run when a coroutine is suspended and then destroyed

[zygoloid]

Example:

#include <coroutine>
#include <iostream>

struct coroutine {
  struct promise_type;
  std::coroutine_handle<promise_type> handle;
  ~coroutine() { handle.destroy(); }
};

struct coroutine::promise_type {
  coroutine get_return_object() {
    return {std::coroutine_handle<promise_type>::from_promise(*this)};
  }
  std::suspend_never initial_suspend() noexcept { return {}; }
  std::suspend_never final_suspend() noexcept { return {}; }
  void return_void() {}
  void unhandled_exception() {}
};

struct Printy {
  Printy(const char *name) : name(name) { std::cout << "Printy(" << name << ")\n"; }
  Printy(const Printy&) = delete;
  ~Printy() { std::cout << "~Printy(" << name << ")\n"; }
  const char *name;
};

int main() {
  [] -> coroutine {
    Printy a("a");
    Printy arr[] = {
      Printy("b"), Printy("c"),
      (co_await std::suspend_always{}, Printy("d")),
      Printy("e")
    };
  }();
}

When the coroutine is destroyed after being suspended, a is destroyed, but arr[0] and arr[1] are not. Clang does not in general properly create cleanups for non-exceptional control flow that occurs in the middle of an expression / an initializer. At least array initialization is missing cleanups here, but it'd be worth checking through all exception-only cleanups because most of them are probably incorrect. It looks like there are 15 places where we currently push an EH-only cleanup:

CGCall.cpp:      pushFullExprCleanup<DestroyUnpassedArg>(EHCleanup, Slot.getAddress(),
CGClass.cpp:    CGF.EHStack.pushCleanup<CallBaseDtor>(EHCleanup, BaseClassDecl,
CGClass.cpp:    EHStack.pushCleanup<CallDelegatingCtorDtor>(EHCleanup,
CGCoroutine.cpp:    EHStack.pushCleanup<CallCoroEnd>(EHCleanup);
CGDecl.cpp:  pushDestroy(EHCleanup, addr, type, getDestroyer(dtorKind), true);
CGDecl.cpp:  pushFullExprCleanup<IrregularPartialArrayDestroy>(EHCleanup,
CGDecl.cpp:  pushFullExprCleanup<RegularPartialArrayDestroy>(EHCleanup,
CGException.cpp:  pushFullExprCleanup<FreeException>(EHCleanup, addr.getPointer());
CGExprAgg.cpp:        CGF.pushDestroy(EHCleanup, LV.getAddress(CGF), CurField->getType(),
CGExprAgg.cpp:        CGF.pushDestroy(EHCleanup, LV.getAddress(CGF), field->getType(),
CGExprCXX.cpp:      .pushCleanupWithExtra<DirectCleanup>(EHCleanup,
CGExprCXX.cpp:    .pushCleanupWithExtra<ConditionalCleanup>(EHCleanup,
ItaniumCXXABI.cpp:    CGF.EHStack.pushCleanup<CallGuardAbort>(EHCleanup, guard);
MicrosoftCXXABI.cpp:    CGF.EHStack.pushCleanup<ResetGuardBit>(EHCleanup, GuardAddr, GuardNum);
MicrosoftCXXABI.cpp:    CGF.EHStack.pushCleanup<CallInitThreadAbort>(EHCleanup, GuardAddr);

This bug is not new with coroutines; the same thing happens with statement expressions:

int main() {
  Printy arr[] = { Printy("a"), ({ return 0; Printy("b"); }) };
}

... never destroys arr[0]. But it seems more pressing now that it's reachable from standard C++20 code.

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-coroutines

[yuxuanchen1997]

I am taking a look at this now.

[yuxuanchen1997]

For those who are reading this, this issue has nothing to do with the less common comma operator syntax shown in the example. If you have a PrintyAwaiter here in the much more common scenario you exhibit the same bug: ~Printy("b") is not run.

task test() {
  Printy a("a");
  Printies p{
    Printy("b"),
    co_await PrintyAwaiter("c"),
    Printy("d"),
  };
  co_return;
}

Also, yes, aggregate initialize is also list initialize. Confirmed to have the same bug.

[yuxuanchen1997]

CodeGenFunction::EmitBranchThroughCleanup ignores cleanups that are not Normal. Simply changing the pushDestroy to push a NormalAndEHCleanup here doesn't seem to work. It calls more destructors than it should.

[usx95]

Interestingly, this is not the case with temporaries associated with function call parameters. This only happens with list/aggregate initialisation.

coroutine foo() {
    Printy a("a");
    // bar(Printy("b"), co_await Awaiter{}); // Fine.

    // (Printy("b"), co_await Awaiter{}); // Fine.

    // Printies p1(Printy("b"),  // Fine.
    //             co_await Awaiter{});

    Printies p2{Printy("b"),  // Leak.
                co_await Awaiter{}};
    co_return;
}

https://godbolt.org/z/x9zKKsoY8

[alanzhao1]

I took a quick stab at this. The following diff resolves the example in the description that doesn't have a coroutine:

diff --git a/clang/lib/CodeGen/CGDecl.cpp b/clang/lib/CodeGen/CGDecl.cpp
index a5da0aa2965a..7c961ef91e6d 100644
--- a/clang/lib/CodeGen/CGDecl.cpp
+++ b/clang/lib/CodeGen/CGDecl.cpp
@@ -2423,7 +2423,7 @@ void CodeGenFunction::pushIrregularPartialArrayCleanup(llvm::Value *arrayBegin,
                                                        QualType elementType,
                                                        CharUnits elementAlign,
                                                        Destroyer *destroyer) {
-  pushFullExprCleanup<IrregularPartialArrayDestroy>(EHCleanup,
+  pushFullExprCleanup<IrregularPartialArrayDestroy>(NormalAndEHCleanup,
                                                     arrayBegin, arrayEndPointer,
                                                     elementType, elementAlign,
                                                     destroyer);

Output:

Printy(a)
~Printy(a)

But that diff causes the example with the coroutine to segfault (when compiled with -stdlib=libc++):

Printy(a)
Printy(b)
Printy(c)
[1]    1813892 segmentation fault  /tmp/coroutine-dtor-maybefixed

[alanzhao1]

Also, observe that gcc doesn't construct Printy(b) and Printy(c) at all: https://godbolt.org/z/hb85j4YzW

[usx95]

Yeah I noticed. In the following example, GCC creates b and c only after the final resumption in the expr and not in the lexical order. godbolt

Printies p2{Printy("b"), co_await Awaiter{"a1"}, Printy("c"), co_await Awaiter{"a2"}};

Clang:

Printy(b)
Coroutine suspended
Coroutine resumed:
Printy(a1)
Printy(c)
Coroutine suspended
Coroutine resumed:
Printy(a2)
~Printy(a2)
~Printy(c)
~Printy(a1)
~Printy(b)
Coroutine destroyed

GCC:

Coroutine suspended
Coroutine resumed:
Coroutine suspended
Coroutine resumed:
Printy(b)
Printy(a1)
Printy(c)
Printy(a2)
~Printy(a2)
~Printy(c)
~Printy(a1)
~Printy(b)
Coroutine destroyed