C++ coroutine causes stack overflow - c++

Question

In Visual Studio 2022 (C++20 build) I get a stack overflow exception with the following code (operator new never gets called) :
struct cCoro
{
struct promise_type
{
cCoro get_return_object() {
return {
// Uses C++20 designated initializer syntax
.Handle = std::coroutine_handle<promise_type>::from_promise(*this)
};
}
std::suspend_always initial_suspend() { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void unhandled_exception() {}
void return_void() {}
void* operator new (size_t sz) {
printf("%s %I64d\n", __FUNCTION__, sz);
return malloc(sz);
}
};
std::coroutine_handle<promise_type> Handle;
};
cCoro stack_or_heap()
{
const int sz = 64 * 1024 * 1024; // larger than a normal thread stack ... blows stack!!!???
uint8_t buffer[sz];
co_await std::suspend_always();
// ... use buffer here
}
int main()
{
auto h = stack_or_heap(); // <== stack overflow here ...
}
Changing the buffer size as follows works (and operator new gets called):
cCoro stack_or_heap()
{
const int sz = 64 * 1024; // Works
uint8_t buffer[sz];
co_await std::suspend_always();
// ... use buffer here
}
I don't understand, are the "local" variables in a C++ coroutine on the stack or not?
I was expecting the allocation to be passed to operator new - irrespective of the size of the buffer. I do not expect to get a stack overflow ...
Looking at godbolt disassembly, the code is adding the buffer size to the stack as it enters the coroutine - and also passing the buffer size and the extra bytes for to coroutine state to operator new
cCoro stack_or_heap(void) PROC ; stack_or_heap
$LN1:
mov eax, 67109128 ; 04000108H
call __chkstk
sub rsp, rax
xor eax, eax
test eax, eax
je SHORT $LN8#stack_or_h
lea rax, QWORD PTR $T2[rsp]
mov QWORD PTR tv73[rsp], rax
jmp SHORT $LN9#stack_or_h
$LN8#stack_or_h:
mov eax, 67109040 ; 040000b0H
mov ecx, eax
call static void * cCoro::promise_type::operator new(unsigned __int64) ; cCoro::promise_type::operator new
mov QWORD PTR tv73[rsp], rax
I don't understand why the thread's stack is involved with the buffer[sz] at all, when this is allocated as part of the C++ coroutine's state (via operator new)? There is no need for the buffer[sz] to be in the stack frame is there?
Why is space being added to the stack frame AND space being allocated via operator new for the same buffer?

Answer 1

Local variables are part of the coroutine's state. Whether they are considered "on the stack" by some definition is a matter for the implementation to work out. C++ implementations are permitted to have all kinds of limitations on how much space is available for various operations, including the size of a coroutine state.
It may consider such a circumstance to be a "stack overflow" if it is due to the coroutine's state exceeding some limitation on the size of the stack which a coroutine function is allowed to use. But again, that's all up to the implementation.
Perhaps the problem is that you're thinking of "the stack" and "the heap" as disjointed concepts. An object is on one or the other, but not both. While this is a conceptually useful distinction, it's not really true.
Memory is memory; at the bottom, there is no "stack memory" or "heap memory".
The term "the heap" usually is used to refer to some pool of memory whose acquisition and release is managed by the application's runtime explicitly. Whereas "the stack" usually refers to memory used by a function's automatic variables, where allocation is managed automatically based on which functions you call in what order.
But this is just a high-level overview. At the bottom, there is just memory.
"The stack" is a region of memory which a particular thread of execution is attached to. That is, when a CPU thread is operating, it has some conceptual region of memory that is its "stack". It does not care where this memory comes from.
The takehome point is this: memory is "the stack" because it is being used as a stack frame. It is not an inherent property of memory, and it has nothing to do with where that memory came from.
The point of a coroutine is that its execution can be paused and resumed. To do this, the content of any local variables must be preserved. But normally, the memory used by a thread's stack is contiguous. To make a coroutine work, the coroutine's local variables must be in storage that is disconnected from any particular thread's stack.
That's where the memory allocation comes in. The coroutine state is a set of data which includes objects used to manage the coroutine, but it also includes a chunk of memory which the coroutine uses as its stack. Storage for this memory must be allocated when the coroutine starts. And when the coroutine is done, it must be deallocated.
Remember: "the stack" does not care where the memory comes from. Memory is a "stack" based on usage, not how it was allocated. So a piece of memory, allocated from "the heap," can in fact be used as a stack. There is no contradiction here.