{"id":112677,"date":"2026-09-07T07:00:00","date_gmt":"2026-09-07T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112677"},"modified":"2026-09-08T08:09:16","modified_gmt":"2026-09-08T15:09:16","slug":"20260907-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260907-00\/?p=112677","title":{"rendered":"Why don’t we allow stacks to be sparse, instead of forcing them to be contiguous?"},"content":{"rendered":"

When I discussed why we don’t just make the entire stack out of guard pages<\/a>, commenter BCS wondered<\/a>, “Why require that the stack use contiguously mapped pages? What would break if only touched pages got mapped in? That could actually be a good thing for example with a function that wanted to alloca<\/code> 512MB on the stack but only read\/writes a few pages.”<\/p>\n

So the question is asking why the stack must be contiguous. Why not let it be sparse and fault in only the pages that are touched?<\/p>\n

The first issue is that the stack check code would have to include an explicit check against the stack limit, instead of just walking down the stack a page at a time. This explicit check is needed to avoid security vulnerabilities if somebody manages to alloca<\/code> a buffer so large that it goes past the end of the stack reservation entirely. If you go a single page at a time, you will eventually hit the no-access page that marks the end of the stack. But if you can leap over multiple pages at a time without touching them, you might leap so far past the end of the stack that you land somewhere else and start corrupting that other memory because you’re using it as a stack. In linux circles, this vulnerability is nicknamed “Stack Clash<\/a>“\u00b9 and goes more formally by “stack guard-page hopping<\/a>.”\u00b2<\/p>\n

After fixing that issue, you have another problem: How would you report a failure to commit a page in the middle of the stack?<\/p>\n

void dosomething()\r\n{\r\n    void* buffer = NULL;\r\n    __try {\r\n        buffer = alloca(65536);\r\n    } __except (GetExceptionCode() == STATUS_STACK_OVERFLOW) {\r\n        if (!_resetstkoflw()) __fastfail(FAST_FAIL_FATAL_APP_EXIT);\r\n    }\r\n\r\n    if (buffer != NULL) {\r\n        \u27e6 use the buffer \u27e7\r\n    }\r\n}\r\n<\/pre>\n
If you allowed sparse stacks, then the memory for the buffer<\/code> would not actually be committed until the code used it. But the point the code uses the buffer is outside<\/i> the exception handler for the failed alloca()<\/code>. The code assumes, not unreasonably, that if alloca<\/code> succeeds, then the memory is indeed allocated.<\/p>\n
I guess you could fix this by committing the memory without making it present. That would mean making a call to Virtual\u00adAlloc<\/code> to expand the stack rather than just accessing the memory. Not only would this make the stack expansion code more complicated, particularly since  you have to preserve all the registers that might possibly be used by any calling convention<\/a>, but you also have to make sure that the Virtual\u00adAlloc<\/code> function itself doesn’t allocate too much stack!<\/p>\n
Now, you can still tweak the x86-32 stack prober to avoid  pete.d<\/a>‘s problem, where a large stack frame is made completely present, with the resulting page-ins creating noticeable performance issues. The x86-32 prober could short-circuit the stack probe (like the MIPS and other processors listed in the table on this page<\/a>) so that the page-ins occur only when the stack is actually expanding.<\/p>\n
\u00b9 Bonus reading about Stack Clash:<\/p>\n