C C maximum stack size of program

Question

I want to do DFS on a 100 X 100 array   Say elements of array represents graph nodes  So assuming worst case  depth of recursive function calls can go upto 10000 with each call taking upto say 20 bytes  So is it feasible means is there a possibility of stackoverflow    What is the maximum size of stack in C C        Please specify for gcc for both   1  cygwin on Windows   2  Unix     What are the general limits

User · Answer

I just ran out of stack at work  it was a database and it was running some threads  basically the previous developer had thrown a big array on the stack  and the stack was low anyway  The software was compiled using Microsoft Visual Studio 2015    Even though the thread had run out of stack  it silently failed and continued on  it only stack overflowed when it came to access the contents of the data on the stack    The best advice i can give is to not declare arrays on the stack - especially in complex applications and particularly in threads  instead use heap  That s what it s there for      Also just keep in mind it may not fail immediately when declaring the stack  but only on access  My guess is that the compiler declares stack under windows  optimistically   i e  it will assume that the stack has been declared and is sufficiently sized until it comes to use it and then finds out that the stack isn t there   Different operating systems may have different stack declaration policies  Please leave a comment if you know what these policies are

User · Answer

Stacks for threads are often smaller  You can change the default at link time  or change at run time also  For reference  some defaults are   glibc i386  x86 64  7 4 MB Tru64 5 1  5 2 MB Cygwin  1 8 MB Solaris 7  10  1 MB MacOS X 10 5  460 KB AIX 5  98 KB OpenBSD 4 0  64 KB HP-UX 11  16 KB

User · Answer

Added 26 Sept  2020  On 24 Oct  2009  as  pixelbeat first pointed out here  Bruno Haible empirically discovered the following default thread stack sizes for several systems  He said that in a multithreaded program   quot the default thread stack size is  quot   - glibc i386  x86 64    7 4 MB - Tru64 5 1             5 2 MB - Cygwin                1 8 MB - Solaris 7  10           1 MB - MacOS X 10 5          460 KB - AIX 5                  98 KB - OpenBSD 4 0            64 KB - HP-UX 11               16 KB   Note that the above units are all in MB and KB  base 1000 numbers   NOT MiB and KiB  base 1024 numbers   I ve proven this to myself by verifying the 7 4 MB case  He also stated that   32 KB is more than you can safely allocate on the stack in a multithreaded program  And he said   And the default stack size for sigaltstack  SIGSTKSZ  is  only 16 KB on some platforms  IRIX  OSF 1  Haiku  only 8 KB on some platforms  glibc  NetBSD  OpenBSD  HP-UX  Solaris  only 4 KB on some platforms  AIX   Bruno  He wrote the following simple Linux C program to empirically determine the above values  You can run it on your system today to quickly see what your maximum thread stack size is  or you can run it online on GDBOnline here  https   onlinegdb com rkO9JnaHD  Explanation  It simply creates a single new thread  so as to check the thread stack size and NOT the program stack size  in case they differ  then it has that thread repeatedly allocate 128 bytes of memory on the stack  NOT the heap   using the Linux alloca   call  after which it writes a 0 to the first byte of this new memory block  and then it prints out how many total bytes it has allocated  It repeats this process  allocating 128 more bytes on the stack each time  until the program crashes with a Segmentation fault  core dumped  error  The last value printed is the estimated maximum thread stack size allowed for your system  Important note  alloca   allocates on the stack  even though this looks like dynamic memory allocation onto the heap  similar to a malloc   call  alloca   does NOT dynamically allocate onto the heap  Rather  alloca   is a specialized Linux function to  quot pseudo-dynamically quot   I m not sure what I d call this  so that s the term I chose  allocate directly onto the stack as though it was statically-allocated memory  Stack memory used and returned by alloca   is scoped at the function-level  and is therefore  quot automatically freed when the function that called alloca   returns to its caller  quot  That s why its static scope isn t exited and memory allocated by alloca   is NOT freed each time a for loop iteration is completed and the end of the for loop scope is reached  See man 3 alloca for details  Here s the pertinent quote  emphasis added    DESCRIPTION The alloca   function allocates size bytes of space in the stack frame of the caller   This temporary space is automatically freed when the function that called alloca   returns to its caller  RETURN VALUE The alloca   function returns a pointer to the beginning of the allocated space   If the allocation causes stack overflow  program behavior is undefined   Here is Bruno Haible s program from 24 Oct  2009  copied directly from the GNU mailing list here  Again  you can run it live online here     By Bruno Haible    24 Oct  2009    Source  https   lists gnu org archive html bug-coreutils 2009-10 msg00262 html                     Program for determining the default thread stack size             include  lt alloca h gt   include  lt pthread h gt   include  lt stdio h gt  void  threadfunc  void p      int n   0    for            printf  quot Allocated  d bytes n quot   n       fflush stdout       n    128         volatile char    alloca 128     0         int main       pthread t thread    pthread create  amp thread  NULL  threadfunc  NULL     for            When I run it on GDBOnline using the link above  I get the exact same results each time I run it  as both a C and a C  17 program  It takes about 10 seconds or so to run  Here are the last several lines of the output   Allocated 7449856 bytes Allocated 7449984 bytes Allocated 7450112 bytes Allocated 7450240 bytes Allocated 7450368 bytes Allocated 7450496 bytes Allocated 7450624 bytes Allocated 7450752 bytes Allocated 7450880 bytes Segmentation fault  core dumped    So  the thread stack size is  7 45 MB for this system  as Bruno mentioned above  7 4 MB   I ve made a few changes to the program  mostly just for clarity  but also for efficiency  and a bit for learning  Summary of my changes    learning  I passed in BYTES TO ALLOCATE EACH LOOP as an argument to the threadfunc   just for practice passing in and using generic void  arguments in C    efficiency  I made the main thread sleep instead of wastefully spinning    clarity  I added more-verbose variable names  such as BYTES TO ALLOCATE EACH LOOP and bytes allocated    clarity  I changed this      volatile char    alloca 128     0   to this   volatile uint8 t   byte buff              volatile uint8 t   alloca BYTES TO ALLOCATE EACH LOOP    byte buff 0    0     Here is my modified test program  which does exactly the same thing as Bruno s  and even has the same results  You can run it online here  or download it from my repo here  If you choose to run it locally from my repo  here s the build and run commands I used for testing   Build and run it as a C program   mkdir -p bin  amp  amp     gcc -Wall -Werror -g3 -O3 -std c11 -pthread -o bin tmp    onlinegdb--empirically determine max thread stack size GS version c  amp  amp     time bin tmp   Build and run it as a C   program   mkdir -p bin  amp  amp     g   -Wall -Werror -g3 -O3 -std c  17 -pthread -o bin tmp    onlinegdb--empirically determine max thread stack size GS version c  amp  amp     time bin tmp    It takes  lt  0 5 seconds to run locally on a fast computer with a thread stack size of  7 4 MB  Here s the program                     Program for determining the default thread stack size               Modified by Gabriel Staples  26 Sept  2020     Originally by Bruno Haible    24 Oct  2009    Source  https   lists gnu org archive html bug-coreutils 2009-10 msg00262 html   include  lt alloca h gt   include  lt pthread h gt   include  lt stdbool h gt   include  lt stdint h gt   include  lt stdio h gt   include  lt unistd h gt     sleep      Thread function to repeatedly allocate memory within a thread  printing     the total memory allocated each time  until the program crashes  The last     value printed before the crash indicates how big a thread s stack size is  void  threadfunc void  bytes to allocate each loop        const uint32 t BYTES TO ALLOCATE EACH LOOP                 uint32 t  bytes to allocate each loop       uint32 t bytes allocated   0      while  true                printf  quot bytes allocated    u n quot   bytes allocated           fflush stdout              NB  it appears that you don t necessarily need  volatile  here             but you DO definitely need to actually use  ex  write to  the            memory allocated by  alloca     as we do below  or else the             alloca    call does seem to get optimized out on some systems             making this whole program just run infinitely forever without            ever hitting the expected segmentation fault          volatile uint8 t   byte buff                    volatile uint8 t   alloca BYTES TO ALLOCATE EACH LOOP           byte buff 0    0          bytes allocated    BYTES TO ALLOCATE EACH LOOP           int main         const uint32 t BYTES TO ALLOCATE EACH LOOP   128       pthread t thread      pthread create  amp thread  NULL  threadfunc                      void    amp BYTES TO ALLOCATE EACH LOOP        while  true                const unsigned int SLEEP SEC   10000          sleep SLEEP SEC              return 0     Sample output  same results as Bruno Haible s original program    bytes allocated   7450240                                                                                                                                                         bytes allocated   7450368                                                                                                                                                         bytes allocated   7450496                                                                                                                                                         bytes allocated   7450624                                                                                                                                                         bytes allocated   7450752                                                                                                                                                         bytes allocated   7450880                                                                                                                                                         Segmentation fault  core dumped

User · Answer

Platform-dependent  toolchain-dependent  ulimit-dependent  parameter-dependent     It is not at all specified  and there are many static and dynamic properties that can influence it

User · Answer

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 lt Node gt  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

User · Answer

I am not sure what you mean by doing a depth first search on a rectangular array  but I assume you know what you are doing   If the stack limit is a problem you should be able to convert your recursive solution into an iterative solution that pushes intermediate values onto a stack which is allocated from the heap

User · Answer

Yes  there is a possibility of stack overflow  The C and C   standard do not dictate things like stack depth  those are generally an environmental issue   Most decent development environments and or operating systems will let you tailor the stack size of a process  either at link or load time   You should specify which OS and development environment you re using for more targeted assistance   For example  under Ubuntu Karmic Koala  the default for gcc is 2M reserved and 4K committed but this can be changed when you link the program  Use the --stack option of ld to do that

[c++] C/C++ maximum stack size of program

Examples related to c++

Examples related to c

Examples related to stack