Boost C++ Libraries: Ticket #12592: Wrongly aligned bottom stack address

olli — Mon, 07 Nov 2016 19:14:52 GMT

As a quick fix (before I get time to fix this issue) you could disable basic runtime checks:

#pragma check_stack(off) or set "Basic Runtime Checks" to default under "C/C++"/"Code Generation"

Mon, 07 Nov 2016 19:34:27 GMT

I don't think that this function is related to the Basic Runtime Checks setting, but is generally used in functions that use more than one page of stack memory (using large local variables). See http://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function.

I'm currently using the prebuilt version of QT, so I can't simply test whether this setting actually removes the call to _chkstk.

However, I do have a different workaround for this issue which works fine for me, so it isn't blocking my work.

Mon, 07 Nov 2016 19:48:25 GMT

Regarding _chkstk see this (stupid) simple code:

#include <array>
#include <cstring>
int main(int argc, char* argv[])
{
  std::array<char, 8192> bar;
  strcpy(bar.data(), argv[0]);
  return 0;
}

results in

int main(int argc, char* argv[])
{
00007FF6323C2C10 B8 18 20 00 00       mov         eax,2018h
00007FF6323C2C15 E8 76 EE 01 00       call        __chkstk (07FF6323E1A90h)
...

The compiler does not generate this call when using a smaller array (like 1024 bytes). Thus it should be easy to reproduce the issue using an array large enough. I can provide you a minimal test case by tomorrow if you like.

attachment set

Tue, 08 Nov 2016 12:39:14 GMT

attachment → wrong_stack_alignment.cpp

minimal test case

Tue, 08 Nov 2016 12:52:19 GMT

I can confirm that MSVC adds __chkstk to any function requesting more than one page of memory regardless of "Basic Runtime Checks", "Disable Security Checks", or other compiler flags, even in fully optimized release builds. It is a Windows NT platform requirement to do these checks. See https://support.microsoft.com/en-us/kb/100775

status changed; resolution set

olli — Sun, 22 Jan 2017 18:21:23 GMT

status new → closed
resolution → worksforme

I've had time to look at this bug in more detail:

The bottom stack is correctly aligned (16-byte) - the problem is that

execution_context<int> source([](execution_context<int> sink, int)

uses the 'fixedsize_stack' with a default size of 64kB. That means that in best case you get an segmentation fault if you excceed the stack size (allocating 7 arrays on the stack).

Windows does not provide segemented (on demand growing) stacks.

If you use the 'protected_fixedsize_stack' you get an guard page appended at the stack. If you access memory from that page an 'stack overflow' exception is raised:

execution_context<int> source(

std::allocator_arg, protected_fixedsize_stack( 64*1024),

[](execution_context<int> sink, int)

In your case you used the fixedsize_stack with a stack size of 64kb, which seams too small for your use case. You should try a larger stack size.

So, I close this bug as 'works for me'.

BTW, to disable optimization for a function you could use '#pragma optimize("",on|off)'

Christian Maaser — Mon, 23 Jan 2017 08:37:38 GMT

The bottom stack address is required to be aligned at a page boundary (4KB) on 64bit Windows. protected_fixedsize_stack uses

void * vp = ::VirtualAlloc( 0, size__, MEM_COMMIT, PAGE_READWRITE);

to allocate its memory, which does have this guarantee (the function allocates on a memory page level). fixedsize_stack however simply uses

void * vp = std::malloc( size_);

which has no such guarantee.

Of course I agree with you that when running out of stack there is no way (other than dynamically resizing the stack) to recover and without a guard page the application will crash at some point due to accessing an unmapped page. However, MSVC's generated _chkstk assumes that

a) there is a guard page (as setup by protected_fixedsize_stack), and

b) the bottom stack address is properly aligned.

In any case _chkstk will attempt to overwrite several bytes in attempt to trigger the dynamic stack resizing mechanism (assumed to be present), but only when the stack is page aligned _chkstk will be limited to the number of additional pages required by the user's function. When the stack is not properly aligned _chkstk will potentially overwrite many more bytes until it crashes because due to assumptions above it fails to find the end of stack and happily loops through process memory (e.g. other fixedsize_stacks from other contexts allocated right next to each other) overwriting several bytes until it reaches unmapped addresses and only then generating an access violation.

Actually, due to the assumptions of _chkstk/Windows use of fixedsize_stack should be discouraged and shouldn't be default on Windows, but that is a different issue.

Thanks for showing how to change the stack allocator. I missed that part and manually patched my copy of Boost to use protected_fixedsize_stack by default.

olli — Mon, 23 Jan 2017 09:58:30 GMT

Replying to Christian Maaser:

Actually, due to the assumptions of _chkstk/Windows use of fixedsize_stack should be discouraged and shouldn't be default on Windows, but that is a different issue.

A solution for fixedsize_stack could be to use

VirtualAlloc()

as in protected_fixedsize_stack but without adding a guard page at the end. On Windows the minimal stack size must be of page size. So fixedsize_stack would allocate a stack of mulitple pages size.

Mon, 23 Jan 2017 14:56:50 GMT

C++17 will probably introduce http://en.cppreference.com/w/cpp/memory/c/aligned_alloc, but until then this sounds like a good solution to me. Generally I think the benefits of fixedsize_stack over protected_fixedsize_stack are virtually non-existent, because the additional guard page does not require any actual memory allocation but only an address space allocation and reliably protects against stack overflows (utilizing _chkstk).

olli — Mon, 29 May 2017 06:02:30 GMT

The next release of boost.context supports Windows-Fibers - of course Windows-Fibers are slower than fcontext.