catch exception in coroutine on windows produces segfault

[kelbon]

I created pr with reproducing bug, its producing segfault (only on windows)

kelbon/kelcoro#48

dd::task<int> foo1(int i) try {
  abc c;
  for (;;) {
    if (i == 42)
      co_return 0;
    co_await std::suspend_always{};

    try {
      bar(c);
      break;
    } catch (std::exception& e) {
      // here `e` already dead, 
      std::cout << '"' << e.what() << '"';
    }
  }
  throw "";
} catch (...) {
  co_return 0;
}

Notes:
memory where exception allocated is dead when catch block starts.

Its important that break in the try block, even if it is switch break, not break for for loop

Access violation reading location 0xFFFFFFFFFFFFFFFF.

corotuine:

[kelbon]

clang --version
clang version 20.1.5
Target: x86_64-pc-windows-msvc
Thread model: posix

[llvmbot]

@llvm/issue-subscribers-coroutines

Author: None (kelbon)

I created pr with reproducing bug, its producing segfault (only on windows)

kelbon/kelcoro#48

dd::task<int> foo1(int i) try {
  abc c;
  for (;;) {
    if (i == 42)
      co_return 0;
    co_await std::suspend_always{};

    try {
      bar(c);
      break;
    } catch (std::exception& e) {
      // here `e` already dead, 
      std::cout << '"' << e.what() << '"';
    }
  }
  throw "";
} catch (...) {
  co_return 0;
}

Notes:
memory where exception allocated is dead when catch block starts.

Its important that break in the try block, even if it is switch break, not break for for loop

Access violation reading location 0xFFFFFFFFFFFFFFFF.

corotuine:

<img width="682" height="196" alt="Image" src="https://github.com/user-attachments/assets/407cee74-eef3-41af-8c5f-a31f9a888967" />

[kelbon]

minimized to

struct job_promise;

struct job {
  using promise_type = job_promise;
  std::coroutine_handle<> handle;
};

struct job_promise {
  static constexpr std::suspend_never initial_suspend() noexcept {
    return {};
  }
  static constexpr std::suspend_never final_suspend() noexcept {
    return {};
  }
  job get_return_object() noexcept {
    return job(std::coroutine_handle<job_promise>::from_promise(*this));
  }
  static constexpr void return_void() noexcept {
  }
  [[noreturn]] static void unhandled_exception() noexcept {
    std::terminate();
  }
};

job foo1() {
  for (;;) {
    co_await std::suspend_always{};

    try {
      throw std::exception();
    } catch (std::exception& e) {
      std::cout << '"' << e.what() << '"'; // < segfault
    }
  }
}

int main() {
  foo1().handle.resume(); // segfault
}

https://godbolt.org/z/xW1jrzPnc

(dont know what happen to gcc)

[kelbon]

Update:

my research has led to the fact that the compiler incorrectly understands what the address of variable e, this code seems like workaround:

    } catch (std::exception& e) {
      auto* x = std::launder(&e);
      std::cout << '"' << x->what() << '"'; // using `e` here == segfault, while `x` valid. Exception is correct, pointer to it - no
   }

[kelbon]

workaround:

catch (my_exception& _e) {
      auto& e = _e;
      use(e);
}

[kelbon]

any updates?

[rnk]

I think there are known open issues with incompatibilities between Windows C++ exception handling and coroutines. I would not consider it production-ready, and I'm not aware of it being a high priority for any project contributor. See open issues #148035 and #121167 .

If this feature and platform configuration is unsupported and unowned, we could fix the docs.

[kelbon]

I think there are known open issues with incompatibilities between Windows C++ exception handling and coroutines. I would not consider it production-ready, and I'm not aware of it being a high priority for any project contributor. See open issues #148035 and #121167 .

If this feature and platform configuration is unsupported and unowned, we could fix the docs.

after provided workaround i dont think its Windows problem, looks like compiler bug

[NewSigma]

after provided workaround i dont think its Windows problem, looks like compiler bug

It's not a windows problem, but a window specific problem.

I think support for windows is best-effort. I do not have windows dev environment, but may try to have a look at it in the next few weeks.

[rnk]

It's not a windows problem, but a window specific problem.

Yes, it's definitely a compiler bug, but unfortunately, coroutines and C++ exceptions interact in complicated ways, and this platform feature combination doesn't seem to be a priority for most contributors at the moment. Speaking for myself and my colleagues, we support Chromium on Windows, and Chromium doesn't use C++ exceptions or coroutines (yet, to my knowledge), and as always, there's an infinite backlog of work to prioritize against these issues taking up people's time.

[NewSigma]

I'm not familiar with Windows exceptions, but it appears we stored pointer to exception object in the coro frame, whereas catchpad expects it to be allocated on the stack.

entry:
  %call.i = tail call noalias noundef nonnull dereferenceable(56) ptr @"??2@YAPEAX_K@Z"(i64 noundef 56) #13
  store ptr @"?foo1@@YA?AUjob@@XZ.resume", ptr %call.i, align 8
  %destroy.addr.i = getelementptr inbounds nuw i8, ptr %call.i, i64 8
  store ptr @"?foo1@@YA?AUjob@@XZ.destroy", ptr %destroy.addr.i, align 8
  %index.addr43.i = getelementptr inbounds nuw i8, ptr %call.i, i64 17
  store i1 false, ptr %index.addr43.i, align 1
  %tmp.reload.addr.i = getelementptr inbounds nuw i8, ptr %call.i, i64 24
  %e.reload.addr.i = getelementptr inbounds nuw i8, ptr %call.i, i64 48
  %_Data.i.i = getelementptr inbounds nuw i8, ptr %call.i, i64 32
  store ptr @"??_7exception@std@@6B@", ptr %tmp.reload.addr.i, align 8
  tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 8 dereferenceable(16) %_Data.i.i, i8 0, i64 16, i1 false)
  invoke void @_CxxThrowException(ptr nonnull %tmp.reload.addr.i, ptr nonnull @"_TI1?AVexception@std@@") #16
          to label %unreachable.i unwind label %catch.dispatch.i

catch.dispatch.i:                                 ; preds = %entry
  %0 = catchswitch within none [label %catch.i] unwind label %catch.dispatch18.i

catch.i:                                          ; preds = %catch.dispatch.i
  %1 = catchpad within %0 [ptr @"??_R0?AVexception@std@@@8", i32 8, ptr %e.reload.addr.i] ; Seems we request %e.reload.addr.i points to stack?

If catchpad prevents saving the exception pointer in the heap, we should avoid collecting allocas that have catchpad users into the coroutine frame. This approach works because a catch block cannot contain suspending points.