[PATCH 1/2] ntdll/tests: Check that creating huge thread stacks should work.

[Gabriel Ivăncescu]

On 07/05/2021 14:44, Rémi Bernon wrote:
> On 5/7/21 1:38 PM, Gabriel Ivăncescu wrote:
>> On 07/05/2021 13:20, Rémi Bernon wrote:
>>> On 5/7/21 12:08 PM, Rémi Bernon wrote:
>>>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>>>> ---
>>>>
>>>> I'm not completely sure what 789c1db18a4e192425da3771cac4726cda77130b
>>>> was for, but it seems to be causing spurious failures. This fix is
>>>> trying to keep the current behavior, but it may be better to completely
>>>> revert the commit as, although less likely, TEB allocation could also
>>>> fail much more often.
>>>>
>>>>   dlls/ntdll/tests/virtual.c | 10 ++++++++++
>>>>   1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/dlls/ntdll/tests/virtual.c b/dlls/ntdll/tests/virtual.c
>>>> index 8f5b0092bea..686b4076801 100644
>>>> --- a/dlls/ntdll/tests/virtual.c
>>>> +++ b/dlls/ntdll/tests/virtual.c
>>>> @@ -488,6 +488,11 @@ static DWORD WINAPI test_stack_size_thread(void 
>>>> *ptr)
>>>>       return 0;
>>>>   }
>>>> +static DWORD WINAPI test_stack_size_dummy_thread(void *ptr)
>>>> +{
>>>> +    return 0;
>>>> +}
>>>> +
>>>>   static void test_RtlCreateUserStack(void)
>>>>   {
>>>>       IMAGE_NT_HEADERS *nt = RtlImageNtHeader( 
>>>> NtCurrentTeb()->Peb->ImageBaseAddress );
>>>> @@ -563,6 +568,11 @@ static void test_RtlCreateUserStack(void)
>>>>       thread = CreateThread(NULL, 0x3ff000, test_stack_size_thread, 
>>>> &args, STACK_SIZE_PARAM_IS_A_RESERVATION, NULL);
>>>>       WaitForSingleObject(thread, INFINITE);
>>>>       CloseHandle(thread);
>>>> +
>>>> +    thread = CreateThread(NULL, 0x80000000, 
>>>> test_stack_size_dummy_thread, NULL, 
>>>> STACK_SIZE_PARAM_IS_A_RESERVATION, NULL);
>>>> +    todo_wine ok(thread != NULL, "CreateThread with huge stack 
>>>> failed\n");
>>>> +    WaitForSingleObject(thread, INFINITE);
>>>> +    CloseHandle(thread);
>>>>   }
>>>>   static void test_NtMapViewOfSection(void)
>>>>
>>>
>>> Eh obviously that fails on 32bit. Anyway, I'm not sure at all about 
>>> the fix, it's maybe something related to allocations that should be 
>>> bottom-up by default?
>>
>> There's a wine-staging patch that does this and fixes some bugs:
>>
>> ntdll-ForceBottomUpAlloc
>>
>> Does it help? Also what happens on Windows if you force top-down 
>> allocation?
> 
> It doesn't help with the regression, because we now forcefully limit the 
> address space where the thread stack / teb can be allocated.
> 
> What I meant was that although I don't know why it's been added, and if 
> the reason was to make sure early threads are allocated on low 
> addresses, maybe making default allocation strategy bottom-up is the 
> correct fix (instead of trying to forcefully put them in the low 2G).
> 
> I think that patch set has been sent already before but it was 
> considered a bit over complicated.

Yeah, but if all allocations are forced bottom-up, not just the thread 
stack/TEB, then the staging patch should already fix this, implicitly.

An interesting thing is if you forced top-down allocation on Windows, do 
they get allocated in low 2G? Info here:

https://tedwvc.wordpress.com/2013/07/16/porting-win32-code-to-64-bit-watch-out-for-pointers/

I think that would explain Windows behavior and whether it special cases 
them or not.