thor: assertion failure while running gcc compilation

[Dennisbonke]

While attempting to run gcc, the following assertion was observed

Assertion failed: event_
In function transition_ at /var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/cancellation.hpp:300

backtrace

(gdb) bt
#0  thor::panic () at ../../../src/managarm/kernel/thor/generic/debug.cpp:160
managarm/managarm#1  thor::PanicSink::finalize (this=<optimized out>) at ../../../src/managarm/kernel/thor/generic/debug.cpp:222
managarm/managarm#2  frg::stack_buffer_logger<thor::PanicSink, 256ul>::_finalize (this=<optimized out>, done=<optimized out>) at /var/lib/managarm-buildenv/build/system-root/usr/share/frigg/include/frg/logging.hpp:111
managarm/managarm#3  frg::stack_buffer_logger<thor::PanicSink, 256ul>::item::~item (this=<optimized out>) at /var/lib/managarm-buildenv/build/system-root/usr/share/frigg/include/frg/logging.hpp:33
managarm/managarm#4  0xffffffff800188e4 in __assert_fail (assertion=0xffffffff801a589c "event_", file=0xffffffff801a581c "/var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/cancellation.hpp", 
    line=300, function=0xffffffff801a587b "transition_") at ../../../src/managarm/kernel/thor/generic/debug.cpp:229
managarm/managarm#5  0xffffffff8000fc89 in async::detail::cancellation_resolver<async::post_ack_agent<thor::RangeToEvict>::poll_operation<async::value_transform_receiver<thor::WorkQueueAffineAwaiter<async::transform_sender<async::post_ack_agent<thor::RangeToEvict>::poll_sender, thor::MemoryView::pollEviction(thor::MemoryObserver*, async::detail::cancellation_token)::{lambda(async::post_ack_handle<thor::RangeToEvict>)#1}> >::Receiver, thor::MemoryView::pollEviction(thor::MemoryObserver*, async::detail::cancellation_token)::{lambda(async::post_ack_handle<thor::RangeToEvict>)#1}> >::try_cancel_fn, async::post_ack_agent<thor::RangeToEvict>::poll_operation<async::value_transform_receiver<thor::WorkQueueAffineAwaiter<async::transform_sender<async::post_ack_agent<thor::RangeToEvict>::poll_sender, thor::MemoryView::pollEviction(thor::MemoryObserver*, async::detail::cancellation_token)::{lambda(async::post_ack_handle<thor::RangeToEvict>)#1}> >::Receiver, thor::MemoryView::pollEviction(thor::MemoryObserver*, async::detail::cancellation_token)::{lambda(async::post_ack_handle<thor::RangeToEvict>)#1}> >::resume_fn>::transition_(unsigned int) (this=<optimized out>, new_bits=<optimized out>)
    at /var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/cancellation.hpp:300
managarm/managarm#6  0xffffffff8008680a in async::post_ack_mechanism<thor::RangeToEvict>::post_operation<thor::WorkQueueAffineAwaiter<async::post_ack_mechanism<thor::RangeToEvict>::post_sender>::Receiver>::start()::{lambda()#1}::operator()() const (this=<optimized out>) at /var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/post-ack.hpp:111
managarm/managarm#7  0xffffffff80085fb3 in async::post_ack_mechanism<thor::RangeToEvict>::post_operation<thor::WorkQueueAffineAwaiter<async::post_ack_mechanism<thor::RangeToEvict>::post_sender>::Receiver>::start (this=0x0)
    at /var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/post-ack.hpp:78
managarm/managarm#8  async::cpo_types::start_cpo::operator()<async::post_ack_mechanism<thor::RangeToEvict>::post_operation<thor::WorkQueueAffineAwaiter<async::post_ack_mechanism<thor::RangeToEvict>::post_sender>::Receiver>&> (
    op=..., this=<optimized out>) at /var/lib/managarm-buildenv/build/system-root/usr/share/libasync/include/async/execution.hpp:53
managarm/managarm#9  thor::WorkQueueAffineAwaiter<async::post_ack_mechanism<thor::RangeToEvict>::post_sender>::await_suspend (this=0xffffc00019789518, h=...)
    at ../../../src/managarm/kernel/thor/generic/thor-internal/coroutine.hpp:65
managarm/managarm#10 thor::ManagedSpace::ManagedSpace(unsigned long, bool)::$_0::operator()(thor::ManagedSpace*, enable_detached_coroutine) const [clone .__await_suspend_wrapper__await2] ()
    at ../../../src/managarm/kernel/thor/generic/memory-view.cpp:1033
managarm/managarm#11 thor::ManagedSpace::ManagedSpace(unsigned long, bool)::$_0::operator()(thor::ManagedSpace*, enable_detached_coroutine) const [clone .resume] (this=<optimized out>, self=0xffffc00018a13218)
    at ../../../src/managarm/kernel/thor/generic/memory-view.cpp:1033
managarm/managarm#12 0xffffffff800dff6d in thor::WorkQueue::run (this=0xffffc000002ffe18) at ../../../src/managarm/kernel/thor/generic/work-queue.cpp:103
managarm/managarm#13 0xffffffff8001a16e in thor::KernelFiber::blockCurrent (blocker=0xffffc0000028feb8) at ../../../src/managarm/kernel/thor/generic/fiber.cpp:19
managarm/managarm#14 0xffffffff8001a645 in thor::KernelFiber::exitCurrent () at ../../../src/managarm/kernel/thor/generic/fiber.cpp:57
managarm/managarm#15 0x0000000000000000 in ?? ()
(gdb)

[avdgrinten]

This is a libasync bug. The safety argument here is wrong: https://github.com/managarm/libasync/blob/master/include/async/cancellation.hpp#L297-L304

We claim

// Note that we enter this code path at most once since done_cancellation_path is the only missing
// bit in state_ and the next call to transition_() will necessarily set it.

and it's true the code path may be reached at most once; however, the next call to transition_() may in fact destroy the entire struct and the code path that the comment is in still touches event_.