Maximum Stack Size for C/C+ Program

C/C++ maximum stack size of program on mainstream OSes

In Visual Studio the default stack size is 1 MB i think, so with a recursion depth of 10,000 each stack frame can be at most ~100 bytes which should be sufficient for a DFS algorithm.

Most compilers including Visual Studio let you specify the stack size. On some (all?) linux flavours the stack size isn't part of the executable but an environment variable in the OS. You can then check the stack size with ulimit -s and set it to a new value with for example ulimit -s 16384.

Here's a link with default stack sizes for gcc.

DFS without recursion:

std::stack<Node> dfs;
dfs.push(start);
do {
    Node top = dfs.top();
    if (top is what we are looking for) {
       break;
    }
    dfs.pop();
    for (outgoing nodes from top) {
        dfs.push(outgoing node);
    }
} while (!dfs.empty())

Maximum Stack Size for C/C+ Program?

I tried below program.

int main()
{
    int nStack[519492];
    cout<<"Okay!";
    return 0;
}

The output:

Okay!

But if I increase the array size by 1 byte, the program crashes.

int main()
{
    int nStack[519493];
    cout<<"Okay!";
    return 0;
}

Output:

No output. Program crashes.

Is there any limit on stack memory?

This all depends on what language and compiler you use. But programs compiled with for instance C or C++ allocate a fixed size stack at program startup. The size of the stack can usually be specified at compile time (on my particular compiler it default to 1 MB).

Default stack size

The default size comes from the .exe, not the OS.

From MSDN:

The default size for the reserved and initially committed stack memory
is specified in the executable file header.

Specifically, the stack reserve and commit sizes are specified in the IMAGE_OPTIONAL_HEADER structure in a PE file. This can usually be set to a specific value with a linker parameter. With the MinGW toolchain you can try something like -Wl,--stack,52428800 as a gcc parameter. This option might exist in the IDE you are using, just look for build and/or linker settings.

This applies to the first thread, other threads can override the default if you specify a non-zero value when you call CreateThread.

Increase stack size in c++

I have solved problem, It should work in all IDEs I think, but it definitely works in Visual Studio. PROJECT->Properties->Configuration Properties->Linker->System->Stack Reserve Size=4194304 . This makes stack size 4 MB.

How to know the stack size limit of .exe program?

From this answer, to check the stack size you need to install Visual Studio and use the visual studio tool dumpbin. Usually there is a script that can be run to bring a command prompt windows with all the visual studio tools in path, this is vcvarsall.bat or "x64 Native Tools Command Prompt for VS 2019" (or something like that) from the start menu.

Run

dumpbin /headers executable.exe

This will return a long output. In that output, look for OPTIONAL HEADER VALUES and in that part, there will be a size of stack reserve . The default stacksize is written as 100000 (bytes) i.e. 1 Megabytes.

You can change the stacksize of an executable by using editbin, also provided by Visual Studio:

editbin /stack:N executable.exe

Here N is the number in bytes for the stacksize.

Why is stack memory size so limited?

My intuition is the following. The stack is not as easy to manage as the heap. The stack need to be stored in continuous memory locations. This means that you cannot randomly allocate the stack as needed, but you need to at least reserve virtual addresses for that purpose. The larger the size of the reserved virtual address space, the fewer threads you can create.

For example, a 32-bit application generally has a virtual address space of 2GB. This means that if the stack size is 2MB (as default in pthreads), then you can create a maximum of 1024 threads. This can be small for applications such as web servers. Increasing the stack size to, say, 100MB (i.e., you reserve 100MB, but do not necessarily allocated 100MB to the stack immediately), would limit the number of threads to about 20, which can be limiting even for simple GUI applications.

A interesting question is, why do we still have this limit on 64-bit platforms. I do not know the answer, but I assume that people are already used to some "stack best practices": be careful to allocate huge objects on the heap and, if needed, manually increase the stack size. Therefore, nobody found it useful to add "huge" stack support on 64-bit platforms.

---

Related Topics