[PATCH] ntdll: Decouple pthread stack and win32 stack.

[Jefferson Carpenter]

Is there any particular reason to place the pthread stack adjacent to 
the win32 stack?  If the pthread stack happened to extend past 
PTHREAD_STACK_MIN while the win32 thread was started, writes to the 
win32 stack (such as the initial CONTEXT) would overwrite the pthread stack.

-Jefferson

[Alexandre Julliard]

Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
> Is there any particular reason to place the pthread stack adjacent to
> the win32 stack?  If the pthread stack happened to extend past
> PTHREAD_STACK_MIN while the win32 thread was started, writes to the
> win32 stack (such as the initial CONTEXT) would overwrite the pthread
> stack.

Do you have a case where this actually happens?  If so, moving the stack
somewhere else is only going to crash or overwrite some other data.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Jefferson Carpenter]

On 8/19/2020 4:03 PM, Alexandre Julliard wrote:
> Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes:
> > Is there any particular reason to place the pthread stack adjacent to
> > the win32 stack?  If the pthread stack happened to extend past
> > PTHREAD_STACK_MIN while the win32 thread was started, writes to the
> > win32 stack (such as the initial CONTEXT) would overwrite the pthread
> > stack.
>
> Do you have a case where this actually happens?  If so, moving the stack
> somewhere else is only going to crash or overwrite some other data.

Sorry, I missed your message.  I do not have a case where that happens.

You are right, that patch wouldn't be correct without at least 
re-enabling the pthread guard area.