Unit test segfaults on coroutines in GCC 15 on master & release

[talisein]

Git commit reference
6915904
Also: tag v10.1.3

Describe the bug
Running the unit test segfaults. The back trace from master is below. This was the first time I was going to try coroutines outside of std::generator, so I'm not sure I can help much more.

0x000000000042ec9f in std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >::resume (this=0x1de8e50) at /usr/include/c++/15/coroutine:247
247	      void resume() const { __builtin_coro_resume(_M_fr_ptr); }
(gdb) bt full
#0  0x000000000042ec9f in std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >::resume (this=0x1de8e50) at /usr/include/c++/15/coroutine:247
No locals.
#1  0x000000000040e7d7 in operator() (__closure=0x1de8e48) at /home/agpotter/git/DPP/src/unittest/coro.cpp:39
        test = 0x1cfe7c0 <CORO_TASK_OFFLINE>
        handle = {_M_fr_ptr = 0x405327 <(anonymous namespace)::task_offline_test()>}
        this = 0x1e43270
#2  0x000000000041866d in std::__invoke_impl<void, (anonymous namespace)::simple_awaitable::await_suspend<dpp::detail::task::promise_t<void> >(std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >)::<lambda()> >(std::__invoke_other, struct {...} &&) (__f=...) at /usr/include/c++/15/bits/invoke.h:63
No locals.
#3  0x0000000000418396 in std::__invoke<(anonymous namespace)::simple_awaitable::await_suspend<dpp::detail::task::promise_t<void> >(std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >)::<lambda()> >(struct {...} &&) (__fn=...) at /usr/include/c++/15/bits/invoke.h:98
No locals.
#4  0x000000000041814e in std::thread::_Invoker<std::tuple<(anonymous namespace)::simple_awaitable::await_suspend<dpp::detail::task::promise_t<void> >(std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >)::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x1de8e48) at /usr/include/c++/15/bits/std_thread.h:303
No locals.
#5  0x0000000000417fda in std::thread::_Invoker<std::tuple<(anonymous namespace)::simple_awaitable::await_suspend<dpp::detail::task::promise_t<void> >(std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >)::<lambda()> > >::operator()(void) (this=0x1de8e48) at /usr/include/c++/15/bits/std_thread.h:310
No locals.
#6  0x0000000000417e8a in std::thread::_State_impl<std::thread::_Invoker<std::tuple<(anonymous namespace)::simple_awaitable::await_suspend<dpp::detail::task::promise_t<void> >(std::__n4861::coroutine_handle<dpp::detail::task::promise_t<void> >)::<lambda()> > > >::_M_run(void) (this=0x1de8e40) at /usr/include/c++/15/bits/std_thread.h:255
No locals.
#7  0x00007ffff4a4e3e4 in std::execute_native_thread_routine (__p=0x1de8e40) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104
        __t = <optimized out>
#8  0x00007ffff487ff54 in start_thread (arg=<optimized out>) at pthread_create.c:448
        ret = <optimized out>
        pd = <optimized out>
        out = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737167476416, -2481759632511134337, 140737167476416, 140737488256288, 115, 140737488256551, -2481759632485968513, -2481707197484034689}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007ffff490332c in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

To Reproduce
Steps to reproduce the behavior:

1. Build release or debug cmake build in GCC 15
2. Run unit test
3. (also trying to use coroutines in a real bot will segfault)

Expected behavior
Coroutines should resume without crashing.

System Details:

• OS: Fedora 42
• gcc version 15.2.1 20250808 (Red Hat 15.2.1-1) (GCC)

[Mishura4]

Unfortunately I am in the middle of moving continents and don't have my pc @braindigitalis

Maybe @ruslan-ilesik can take a look

[ruslan-ilesik]

I can confirm the issue, i was able to reproduce it in my VM

[Mishura4]

Possibly related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930

IF this is the same bug then this isn't on us. Needs more investigation

[Mishura4]

Initial review (https://discord.com/channels/825407338755653642/825411104208977952/1417136351626793011) failed to find an issue with the test. Next step would be to try & reproduce a smaller version of the bug. Unfortunately I'll be weeks without a PC still

[talisein]

The following complete program isolates what the unittest is doing. I think its pretty freaky that the lambda gets destroyed while its still running (the stack variables are still alive). I don't know enough about coroutines or dpp::job to know if this is all expected or not though.

The program output (gcc 15.2):

Canary 'lambda' is born
task_offline_test(): co_await simple_awaitable...
Inside simple_awaitable::await_suspend, about to detach thread
Canary 'lambda stack variable' is born
lambda(): co_await dpp::task...
Canary 'lambda' is dead
main(): resuming execution. Sleeping...
Inside simple_awaitable::await_suspend thread
Inside simple_awaitable::await_suspend thread: Finished 5s sleep
Inside simple_awaitable::await_suspend thread: About to resume handle...
Segmentation fault (core dumped)

On gcc 14.2, the program has the same output, except doesn't segfault and continues

Inside simple_awaitable::await_suspend thread: About to resume handle...
task_offline_test(): simple_awaitable has returned, about to co_return myself. (simple_awaitable is destroyed now)
lambda(): co_await dpp::task returned.
Canary 'lambda stack variable' is dead
main(): Sleep completed, we didn't crash yet? You fixed the problem.

#include <thread>
#include <iostream>
#include <dpp/dpp.h>

namespace std_coroutine = dpp::detail::std_coroutine;

struct simple_awaitable {
  volatile int value{};
  int result{};

  bool await_ready() const noexcept {
    return false;
  }

  template <typename T>
  void await_suspend(std_coroutine::coroutine_handle<T> handle) {
    std::thread th([this, handle]() mutable {
      std::cerr << "Inside simple_awaitable::await_suspend thread\n";
      std::this_thread::sleep_for(std::chrono::seconds(5));
      std::cerr << "Inside simple_awaitable::await_suspend thread: Finished 5s sleep\n";
      result = value;
      try {
        std::cerr << "Inside simple_awaitable::await_suspend thread: About to resume handle...\n";
        handle.resume();
      } catch (const std::exception &) {
        /* no exception should be caught */
        std::cerr << "Inside simple_awaitable::await_suspend thread: went to exception\n";
      }
    });
    std::cerr << "Inside simple_awaitable::await_suspend, about to detach thread\n";
    th.detach();
  }

  int await_resume() const noexcept {
    return result;
  }
};


dpp::task<void> task_offline_test() {
  std::cerr << "task_offline_test(): co_await simple_awaitable...\n";
  if (int ret = co_await simple_awaitable{42}; ret != 42) {
    std::cerr << "failed simple awaitable: expected return value not 42\n";
  }
  std::cerr << "task_offline_test(): simple_awaitable has returned, about to co_return myself. (simple_awaitable is destroyed now)\n";
  co_return;
}

struct canary {
  std::string_view name;
  canary(std::string_view name) : name(name) { std::cerr << "Canary '" << name << "' is born\n"; }
  ~canary() { std::cerr << "Canary '" << name << "' is dead\n"; }
};

int main()
{
  [c = canary{"lambda"}]() -> dpp::job {
    dpp::task task = task_offline_test();
    auto c2 = canary{"lambda stack variable"};
    try {
      std::cerr << "lambda(): co_await dpp::task...\n";
      co_await dpp::task{std::move(task)};
      std::cerr << "lambda(): co_await dpp::task returned.\n";
    } catch (const std::exception &e) {
      std::cerr << "Test threw unexpected exception: " << e.what() << "\n";
    } catch (...) {
      std::cerr << "Test threw something unexpected\n";
    }
  }();
  std::cerr << "main(): resuming execution. Sleeping...\n";

  std::this_thread::sleep_for(std::chrono::seconds(10));

  std::cerr << "main(): Sleep completed, we didn't crash yet? You fixed the problem.\n";

  return 0;
}

[Mishura4]

Yes actually with dpp::job that's expected. This is the infamous "The bug is in the standard" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111

Is that what the tests are doing? Then that's definitely wrong on our part

[Mishura4]

Clarifying, I mean the capture specifically is expected to be UB on use

[Mishura4]

No, after looking at the tests again, none of the dpp::job tests capture, so this is unrelated.

[Mishura4]

NO, after looking at your code again, that's not what's happening here either, oops!

Yeah that still doesn't really reduce it. I'll just need to dig into dpp::task's internals when I have my PC again

Just to clarify yes it's expected that canary is destroyed at the co_await, see the bugzilla thread I linked above. With that said you don't use it anyways so that's not a problem here

[talisein]

For reference, the code I gave above is adapted from the v10.1.3 release:
simple_awaitable is from coro.cpp:23
task_offline_test is from coro.cpp:147
The lambda is from coro.cpp:494

The captured canary was just from me poking at things, it crashes without it. At one point I had that section in a non-lambda real function and it crashed as well.

[talisein]

I made a testcase and ran against upstream gcc. For the record, the current master branch (gcc-16) continues to fail. Git bisect narrowed it down to this commit: gcc-mirror/gcc@a169a47

That commit message mentions further work, that's in gcc-mirror/gcc@b4da8ee

The CWG2563 issue is here.