c Windows 32bit malloc() return NULL when opening many threads-CodePudding

I have a sample C program as below:

#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
    void * pointerArr[20000];
    int i = 0, j;
    for (i = 0; i < 20000; i  ) {
        
        void * pointer = malloc(131125);
        if (pointer == NULL) {
            printf("i = %d, out of memory!\n", i);
            getchar();
            break;
        } 
        
        pointerArr[i] = pointer;
    }

    for (j = 0; j < i; j  ) {
        free(pointerArr[j]);
    }

    getchar();
    return 0;
}

When I run it with Visual Studio 32-bit Debug, it will run with following result:

The program can use nearly 2Gb of memory before out of memory.
This is normal behavior.

However, when I adding the code to start Thread inside the for loop as below:

#include <windows.h>
#include <stdio.h>

DWORD WINAPI thread_func(VOID* pInArgs)
{
    Sleep(100000);
    return 0;

}

int main(int argc, char* argv[])
{
    void * pointerArr[20000];

    int i = 0, j;
    for (i = 0; i < 20000; i  ) {

        CreateThread(NULL, 0, thread_func, NULL, 0, NULL);
        
        void * pointer = malloc(131125);
        if (pointer == NULL) {
            printf("i = %d, out of memory!\n", i);
            getchar();
            break;
        }

        pointerArr[i] = pointer;
    }

    for (j = 0; j < i; j  ) {
        free(pointerArr[j]);
    }

    getchar();
    return 0;
}

The result is as below: The memory is still just around 200Mb but function malloc will return NULL.
Could anyone help explain why the program cannot use the memory up to 2Gb before out of memory?
Is it mean creating many threads like above will cause memory leak?

In my real application, this error occur when I create about 800 threads, the RAM memory at the time "out of memory" is around 300Mb.

CodePudding user response：

As noted in a comment by @macroland, the main thing happening here is that each thread is consuming 1 MiB for its stack (see MSDN CreateThread and Thread Stack Size). You say malloc returns NULL once the total you have directly allocated reaches 200 MB. Since you are allocating 131125 bytes at a time, that is 200 MB / 131125 B = 1525 threads. Their cumulative stack space will be around 1.5 GB. Adding the 200 MB of malloc memory is 1.7 GB, and miscellaneous overhead likely accounts for the rest.

So, why does Task Manager not show this? Because the full 1 MiB of thread stack space is not actually allocated (also called committed), rather it is reserved. See VirtualAlloc and the MEM_RESERVE flag. The address space has been reserved for expansion up to 1 MiB, but initially only 64 KiB are allocated, and Task Manager only counts the latter. But reserved memory will not be unilaterally repurposed by malloc until the reservation is lifted, so once it runs out of available address space, it has to return NULL.

What tool can show this? I don't know of anything off the shelf (even Process Explorer does not seem show a count of reserved memory). What I have done in the past is write my own little routine that uses VirtualQuery to enumerate the entire address space, including reserved ranges. I recommend you do the same; it's not much code to write, and very handy when coding for 32-bit Windows because the 2 GiB address space gets cramped very easily (DLLs are an obvious reason, but the default malloc also will leave unexpected reservations behind in response to certain allocation patterns even if you free everything).

In any case, if you want to create thousands of threads in a 32-bit Windows process, be sure to pass a non-zero value as the dwStackSize parameter to CreateThread, and also pass STACK_SIZE_PARAM_IS_A_RESERVATION as dwCreationFlags. The minimum is 64 KiB, which will be plenty if you avoid recursive algorithms in the threads.

Addendum: In a comment, @iinspectable cautions against using thousands of threads, citing Raymond Chen's 2005 blog post Does Windows have a limit of 2000 threads per process?. I agree that doing so is questionable for a variety of reasons; it is not my intent to endorse the practice, rather I'm just explaining one necessary element.