SIGSEGV with co_await (stdexec::get_scheduler() | ...);

Summary

Using co_await (ex::get_scheduler() | ex::let_value([](auto sch) { return ex::schedule(sch); })); in a task leads to a premature exit of sync_wait and a subsequent use-after-free of the coroutine.
This is a regression introduced with 482c260 #2078

Tested with Clang and GCC on x86_64

Workaround

            auto sch = co_await ex::get_scheduler();
            co_await (ex::just(sch) | ex::let_value([](auto sch) { return ex::schedule(sch); }));

Reproducer

https://godbolt.org/z/WE9fs5WPv

#include <coroutine>
#include <stdexec/execution.hpp>
#include <exec/task.hpp>

namespace ex = STDEXEC;

void foo()
{
    int order[2] = {0, 0};
    size_t idx = 0;
    ex::sync_wait(
        [&]() -> ex::task<void> /* or exec::task<void> */ {
            order[idx++] = 1;
            co_await (ex::get_scheduler() | ex::let_value([](auto sch) { return ex::schedule(sch); }));
            order[idx++] = 2;
        }());
}

void foo_workaround()
{
    int order[2] = {0, 0};
    size_t idx = 0;
    ex::sync_wait(
        [&]() -> ex::task<void> /* or exec::task<void> */ {
            order[idx++] = 1;
            auto sch = co_await ex::get_scheduler();
            co_await (ex::just(sch) | ex::let_value([](auto sch) { return ex::schedule(sch); }));
            order[idx++] = 2;
        }());
}

int main()
{
    foo(); // crashes with SIGSEGV probaly use after free
    foo_workaround();
}

/* my usage:
namespace Tools
{
    // Give control back to the scheduler.
    struct Yield : ex::sender_adaptor_closure<Yield>
    {
        auto operator()() const
        {
            return ex::get_scheduler() | ex::let_value([](auto sch) { return ex::schedule(sch); });
        }

        template<class Sndr>
        auto operator()(Sndr sndr) const;
    };

    inline constexpr Yield yield{};

    template<class Sndr>
    auto Yield::operator()(Sndr sndr) const
    {
        return std::move(sndr) | ex::let_value([](auto... value) {
                   return ex::when_all(ex::just(std::move(value)...), Tools::yield());
               });
    }
} 

void foo_intended_use()
{
    int order[4] = {0, 0, 0, 0};
    size_t idx = 0;
    ex::sync_wait(
        ex::when_all(
            [&]() -> ex::task<void> /* or exec::task<void> */ {
                order[idx++] = 1;
                auto sch = co_await ex::get_scheduler();
                co_await Tools::yield();
                order[idx++] = 2;
            }(),
            [&]() -> ex::task<void> /* or exec::task<void> */ {
                order[idx++] = 3;
                auto sch = co_await ex::get_scheduler();
                co_await Tools::yield();
                order[idx++] = 4;
            }()));
    assert(order[0] == 1);
    assert(order[1] == 3);
    assert(order[2] == 2);
    assert(order[3] == 4);
}
*/

Analysis

We analyzed this on 307b83c5689ea7c2e5b31561cdc428697705333e and fee4d651494014610a277540f209cae56011e47f with our intended code, but without the when_all.
We debugged it and it seems, that after the co_await Tools::yield() the sync_wait returns, because __coroutine_unhandled_stopped is called. This leads then to the destruction of the coroutine handle and then a use-after-free once the run_loop wants to execute the rest of the task:

include/stdexec/__detail/__as_awaitable.hpp

    // When the sender is known to complete inline, we can connect and start the operation
    // in await_suspend.
    template <class _Promise, sender_in<env_of_t<_Promise&>> _Sender>
      requires __completes_inline<_Sender, env_of_t<_Promise&>>
    struct __sender_awaiter<_Promise, _Sender>
      : __sender_awaiter_base<__value_t<_Sender, _Promise>, true>
    {
...
      auto await_suspend([[maybe_unused]] __std::coroutine_handle<> __continuation)
        -> __std::coroutine_handle<>
      {
        STDEXEC_ASSERT(this->__continuation_.handle() == __continuation);
        {
          auto __opstate = STDEXEC::connect(static_cast<_Sender&&>(__sndr_), __receiver_t(*this));
          // The following call to start will complete synchronously, writing its result
          // into the __result_ variant.
          STDEXEC::start(__opstate);         // yields continuation was added here
        }

        return this->__get_continuation();   // sync_wait will return after this.
      }
...
    };
...
      [[nodiscard]]
      constexpr auto __get_continuation() const noexcept -> __std::coroutine_handle<>
      {
        // If the operation was stopped (__result_ is valueless), we should use the
        // unhandled_stopped() continuation. Otherwise, should resume the __continuation_
        // as normal.
        if (__result_.__is_valueless()) // after Tools::yield() __result_ is considered valueless because set_value was not called
        {
          return STDEXEC::__coroutine_unhandled_stopped(__continuation_); // sync_wait returns because of this
        }
        else
        {
          return __continuation_.handle();
        }
      }

edit: added variant with exec::task<void> instead of stdexec::task<void>

There is a stack-use-after-return, see https://godbolt.org/z/Taqqc8hjT.
Note:

stdexec/include/stdexec/__detail/__let.hpp

Lines 655 to 659 in 02d671d

    
           static constexpr auto __get_attrs = 
        
             []<class _Child>(__ignore, __ignore, _Child const & __child) noexcept -> decltype(auto) 
        
           { 
        
             // TODO(ericniebler): this needs a proper implementation 
        
             return __fwd_env(STDEXEC::get_env(__child));

I think this is the same underlying issue that #2077 is addressing.

The failure does not appear to be caused directly by sync_wait or by the stopped path. The earlier problem is that, before #2077, the let_* sender's attributes effectively forwarded the predecessor sender's attrs. For example:

get_scheduler() | let_value([](auto sch) { return schedule(sch); })

Here the predecessor is read_env(get_scheduler), whose completion behavior is always __completion_behavior::__inline_completion. Since let_value forwarded that metadata, the whole composed sender could be classified as satisfying __as_awaitable::__completes_inline.

That classification is incorrect: the secondary sender returned by the let_value function is schedule(sch), which may complete asynchronously.

See:

stdexec/include/stdexec/__detail/__as_awaitable.hpp

Lines 369 to 381 in 02d671d

    
           auto await_suspend([[maybe_unused]] __std::coroutine_handle<> __continuation) 
        
             -> __std::coroutine_handle<> 
        
           { 
        
             STDEXEC_ASSERT(this->__continuation_.handle() == __continuation); 
        
             { 
        
               auto __opstate = STDEXEC::connect(static_cast<_Sender&&>(__sndr_), __receiver_t(*this)); 
        
               // The following call to start will complete synchronously, writing its result 
        
               // into the __result_ variant. 
        
               STDEXEC::start(__opstate); 
        
             } 
        
             return this->__get_continuation(); 
        
           }

Once as_awaitable takes the inline-specialized path, it creates the operation state for the whole composed sender as a local variable in await_suspend().

When that composed operation is started, let_value first completes the predecessor inline and then starts the secondary sender, schedule(sch). The operation state for that secondary schedule operation is stored as a subobject inside the composed let_value operation state.

See:

stdexec/include/stdexec/__detail/__run_loop.hpp

Lines 148 to 154 in 02d671d

    
             STDEXEC_ATTRIBUTE(host, device) 
        
             constexpr void start() noexcept 
        
             { 
        
               __task_count_->fetch_add(1, __std::memory_order_release); 
        
               __queue_->push(this); 
        
             } 
        
           };

The schedule operation can then enqueue a pointer to its own nested operation state into the run_loop used by sync_wait. If await_suspend() returns before the queued operation completes, the outer local operation state is destroyed, and the queued scheduler node may point to a subobject that has already gone out of scope.

The approach in #2077 looks like the right fix to me: compute the let_* sender's attributes from the transformed completion information of the secondary senders, rather than simply exposing the predecessor's attrs. With that change, this composed sender should no longer be treated as fully inline when the secondary schedule operation can complete asynchronously.

We figured out a Sender-Receiver implementation, which seems to work with our use-cases. Not sure if entirely correct. The idea is simple. We wrap the original receiver in a forward receiver, which checks the stop_token on the sender's (yield's) set_value completion and translate it into a set_stopped rather than continuing with the next continuation.
We additionally need to advertise completion_behavior_t<stdexec::set_value_t> as exec::completion_behavior::asynchronous_affine. Otherwise the original sender will still be executed.

This works on fee4d65 and 6bac4e1

    struct Yield : sender_adaptor_closure<Yield>
    {
    private:
        template<class Rcvr>
        struct Opstate
        {
            using operation_state_concept = stdexec::operation_state_t;

            struct FwdRcvr
            {
                using receiver_concept = stdexec::receiver_t;
                Rcvr* rcvr;

                void set_value() && noexcept
                {
                    // Re-check cancellation after the reschedule completes. The run loop cannot
                    // cancel operations that were already enqueued (NVIDIA/stdexec issue 2098),
                    // because the sender is wrongly marked as "completes inline" so the stop
                    // token is not checked before starting the operation. A stop requested while
                    // this operation was waiting in the queue can only be observed here, once it
                    // has been dequeued.
                    if (stdexec::get_stop_token(stdexec::get_env(*rcvr)).stop_requested())
                        stdexec::set_stopped(std::move(*rcvr)); // Don't run the original sender
                    else
                        stdexec::set_value(std::move(*rcvr)); // Run the original sender
                }
                void set_error(std::exception_ptr error) && noexcept
                {
                    stdexec::set_error(std::move(*rcvr), std::move(error));
                }
                void set_stopped() && noexcept { stdexec::set_stopped(std::move(*rcvr)); }
                decltype(auto) get_env() const noexcept { return stdexec::get_env(*rcvr); }
            };

            using Sched = decltype(stdexec::get_scheduler(stdexec::get_env(std::declval<Rcvr&>())));
            using ScheduleSender = decltype(stdexec::schedule(std::declval<Sched&>()));
            using ChildOp = stdexec::connect_result_t<ScheduleSender, FwdRcvr>;

            explicit Opstate(Rcvr receiver)
                : rcvr(std::move(receiver))
                , childOp(stdexec::connect(
                          stdexec::schedule(stdexec::get_scheduler(stdexec::get_env(rcvr))),
                          FwdRcvr{&rcvr}))
            {}

            void start() noexcept
            {
                auto stopToken = stdexec::get_stop_token(stdexec::get_env(rcvr));
                if (stopToken.stop_requested())
                {
                    stdexec::set_stopped(std::move(rcvr));
                    return;
                }
                stdexec::start(childOp);
            }

            Rcvr rcvr;
            ChildOp childOp;
        };

        struct Sender
        {
            using sender_concept = stdexec::sender_t;
            using completion_signatures = stdexec::completion_signatures<
                    stdexec::set_value_t(),
                    stdexec::set_error_t(std::exception_ptr),
                    stdexec::set_stopped_t()>;

            // Manually advertise the completion behavior. Because of NVIDIA/stdexec issue 2098, the
            // sender is wrongly marked as "completes inline", so we need to explicitly indicate
            // that it completes asynchronously.
            struct Attrs
            {
                constexpr auto query(
                        exec::get_completion_behavior_t<stdexec::set_value_t>) const noexcept
                {
                    return exec::completion_behavior::asynchronous_affine;
                }
            };

            auto get_env() const noexcept -> Attrs { return {}; }

            template<class Rcvr>
            auto connect(Rcvr&& rcvr)
            {
                return Opstate<std::remove_cvref_t<Rcvr>>{std::forward<Rcvr>(rcvr)};
            }
        };

    public:
        auto operator()() const -> Sender { return {}; }
        template<class Sndr>
        auto operator()(Sndr sndr) const;
    };

    inline constexpr Yield yield{};

    template<class Sndr>
    auto Yield::operator()(Sndr sndr) const
    {
        return std::move(sndr) | stdexec::let_value([](auto... value) {
                   return stdexec::when_all(stdexec::just(std::move(value)...), yield());
        });
    }

@ReneOschmann

No longer reproduces for me against current main (f4c123f7, Apple clang 21, -O2): 200 runs of the repro from this issue all complete in order, and it's clean under ASAN and TSAN.

I bisected it: still broken at 9a301946~1 (hangs instead of completing), works at 9a301946 — "fix(read_env): advertise inline_completion only for the tags it sends". That matches the analysis above: get_scheduler() was advertising inline completion for tags it doesn't send, so the co_await took the completes-inline path in __sender_awaiter, and the inline completion made the awaiter treat its result as valueless and bail through __coroutine_unhandled_stopped.

Looks closable. @ReneOschmann — worth a quick check on your side in case it still shows up on x86_64 Linux; I could only test arm64 macOS.

@alwaysprince05

@alwaysprince05 : Sorry for the late reply I tested on 6bac4e1 which contains 9a30194 and it does not work in my scenario on x86_64 Linux and the above implementation. One correction I have to make. We were using exec::task rather than stdexec::task (I'll make the edit above)

Also the current state of #2216 doesn't seem to work. I will try to port our stuff from exec::task to stdexec::task maybe that's the culprit.

Thanks for the correction — exec::task vs stdexec::task was a real gap in what I tested. I went back and tested both types explicitly.

exec::task turns out not to be the differentiator: both task implementations route the co_await through STDEXEC::as_awaitable (stdexec::task at __task.hpp:889, exec::task at task.hpp:605), so the read_env change applies to both. The reason it is fixed is that __completes_inline needs all three tags inline-or-never-sent, and read_env no longer claims set_stopped_t — which it never sends. let_value forwards the predecessor's environment, so that claim was what made the whole composition look inline.

Concretely, on 0ad49535 (arm64 macOS, Apple clang 21, -O2) and in an emulated x86_64 Linux gcc-13 container:

the issue's expression as exec::task<void>: 200/200 in order, ASAN-clean;
your Tools::yield scenario, one task and two tasks under when_all, for both task types: 200/200, with the interleaving you assert in the issue;
each of those cases dies at 482c2605 (SIGSEGV), so they do reach the buggy path.

Two things I could not test: native x86_64 Linux with your toolchain (mine is emulated amd64), and the custom sender with the hand-written Attrs from your snippet, which is truncated in the paste. 6bac4e1 is also 119 commits behind current main, so a retest pinned to a current SHA would say more than my results do.

I'm not treating this as closable on my evidence — an x86_64 report beats an emulated non-reproduction. If you can point at the yield path and tell me whether it segfaults or hangs, and on which SHA, I'll take that and dig in.

test: pin read_env's completion-behavior claims for get_scheduler() (N…

Thanks for following up.

6bac4e1 is also 119 commits behind current main, so a retest pinned to a current SHA would say more than my results do.

It is always a bit of effort for us to upgrade externals. I did however manually apply the current state of #2216 on top of that. I will test with newer SHA's as soon as I have time.

I could not test: native x86_64 Linux with your toolchain

Just for the record, I am currently testing on x86_64 with clang19 and we use c++20

the custom sender with the hand-written Attrs from your snippet, which is truncated in the paste

I updated the comment with the definition of the operator just for completeness.

If you can point at the yield path and tell me whether it segfaults or hangs, and on which SHA, I'll take that and dig in.

I think last I tried, the segfault itself didn't happen, but the the assertions outlined in my initial example failed i.e. the interleaving was not happening. We always took this as indication, that the problematic inline code-path is involved and the crash just doesn't happen by chance. If you think this should be treated as a separate issue, I can also split it off. If that is actually intended behaviour then I would be happy to get educated on the why, because then my understanding of the schedule() is lacking.

test: pin read_env's completion-behavior claims for get_scheduler() (#…

@mhoemmen

@mhoemmen @ericniebler would you be able to take a look at this?

@ReneOschmann

@ReneOschmann thanks, that helps. I retried the interleaving case specifically, this time closer to your setup: clang 19.1.7 on x86_64 Linux (an emulated amd64 container, so not quite native), -std=c++20 with ASan, plus arm64 macOS. I ran it against plain 6bac4e1 and against current main (7ea2b1b).

I ran 200 iterations each of the original expression from the issue, your foo_intended_use (two tasks under when_all, get_scheduler then Tools::yield()), and the just(7) | Tools::yield overload that goes through when_all(just(value...), yield()). I tried both exec::task and stdexec::task. All of them came out 1,3,2,4 with nothing from ASan. The same test does blow up under ASan at 482c260, so it is hitting the old bug path.

So on 6bac4e1 by itself I get the interleaving you expect. The one difference left from your build is #2216 applied on top. Could you try your case on 6bac4e1 without #2216? If the order comes back right, the problem is coming from #2216 and not this issue. If it still fails, a small godbolt repro would help a lot, since godbolt has x86_64 clang with stdexec trunk.

@WillTrojak

@WillTrojak Hi! We'll take a look at this. Thanks for reporting this issue!

Navigation Menu

Repository navigation

SIGSEGV with `co_await (stdexec::get_scheduler() | ...);` #2098

Summary

Workaround

Reproducer

Analysis

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	static constexpr auto __get_attrs =
	[]<class _Child>(__ignore, __ignore, _Child const & __child) noexcept -> decltype(auto)
	{
	// TODO(ericniebler): this needs a proper implementation
	return __fwd_env(STDEXEC::get_env(__child));

	auto await_suspend([[maybe_unused]] __std::coroutine_handle<> __continuation)
	-> __std::coroutine_handle<>
	{
	STDEXEC_ASSERT(this->__continuation_.handle() == __continuation);
	{
	auto __opstate = STDEXEC::connect(static_cast<_Sender&&>(__sndr_), __receiver_t(*this));
	// The following call to start will complete synchronously, writing its result
	// into the __result_ variant.
	STDEXEC::start(__opstate);
	}

	return this->__get_continuation();
	}

	STDEXEC_ATTRIBUTE(host, device)
	constexpr void start() noexcept
	{
	__task_count_->fetch_add(1, __std::memory_order_release);
	__queue_->push(this);
	}
	};

SIGSEGV with co_await (stdexec::get_scheduler() | ...); #2098

Description

Summary

Workaround

Reproducer

Analysis

Activity

Cra3z commented on Jun 2, 2026

ReneOschmann commented on Sep 15, 2026

alwaysprince05 commented on Oct 5, 2026

ReneOschmann commented on Oct 15, 2026

alwaysprince05 commented on Oct 15, 2026

ReneOschmann commented on Oct 16, 2026

WillTrojak commented on Oct 29, 2026

alwaysprince05 commented on Oct 31, 2026

mhoemmen commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

SIGSEGV with `co_await (stdexec::get_scheduler() | ...);` #2098