Re: [Boost-bugs] [Boost C++ Libraries] #12592: Wrongly aligned bottom stack address

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #12592: Wrongly aligned bottom stack address
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2017-01-23 08:37:38

#12592: Wrongly aligned bottom stack address
-------------------------------------------------+-------------------------
  Reporter:  Christian Maaser                    |      Owner:  olli
  <runningwithscythes@…>                         |     Status:  closed
      Type:  Bugs                                |  Component:  context
 Milestone:  To Be Determined                    |   Severity:  Problem
   Version:  Boost 1.62.0                        |   Keywords:
Resolution:  worksforme                          |
-------------------------------------------------+-------------------------

Comment (by Christian Maaser):

 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/12592#comment:6>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.