Thread: Is there a explicit limit on the main thread stack size?

  1. #1
    Registered User HelpfulPerson's Avatar
    Join Date
    Jun 2013
    Location
    Over the rainbow
    Posts
    288

    Is there a explicit limit on the main thread stack size?

    I was wondering this, because I have a structure in a fairly large project I work on consistently that seems to grow exponentially by the day. I don't know if in C the stack grows automatically if you reach the limit or if you have to handle that somehow yourself. If it helps, I run my programs on Windows 7 with the IDE Code::Blocks and GCC. Just in case it is compiler-dependent/system-dependent.
    "Some people think they can outsmart me, maybe. Maybe. I've yet to meet one that can outsmart bullet" - Meet the Heavy, Team Fortress 2

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Stack has nothing to do with C. The C standard is silent on the topic of stack size (in fact, it doesn't mention a stack at all).

    The notion of stack itself is actually system dependent. Modern operating systems normally manage stack (memory used as scratch space by a running program or process) and heap (memory that a program is permitted to allocate dynamically) via quotas. The quota for stack is tuned to find a balance, considered sensible by the operating system designer, between available resources (the available physical and virtual memory gives a hard upper limit on quotas for both stack and heap size), the needs of typical user and system programs, and the number of user and system programs that an OS needs to host (i.e. execute) at once. Depending on operating system, the quotas can be tweaked by the system administrator on a system-wide basis, a group (of users) basis, and even on a per-process basis (processes with sufficient privilege can change their quotas to suit their needs, and control quotas of other processes).

    Generally speaking, stack needed by a program is only loosely related (at best) to project size or program size.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    Registered User HelpfulPerson's Avatar
    Join Date
    Jun 2013
    Location
    Over the rainbow
    Posts
    288
    Quote Originally Posted by grumpy View Post
    Generally speaking, stack needed by a program is only loosely related (at best) to project size or program size.
    Well, I know my project size wouldn't matter. I'm just saying I keep all my data in a main structure that functions as a storage device for all my functions. I was wondering what might happen if I unintentionally go over that quota you mentioned in your post.
    "Some people think they can outsmart me, maybe. Maybe. I've yet to meet one that can outsmart bullet" - Meet the Heavy, Team Fortress 2

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    If your program (or process) attempts to go over a quota, it would typically not be allowed to start - the process of launching the executable would fail. Some program launchers would adjust quotas and make subsequent attempts to re-launch, but those sorts of things are unusual.

    From a basic architectural perspective, I'd query why your program needs to keep all its data in a global structure in the first place. Such techniques implicitly limit the ability of a program to evolve, usually before any problems with stack quota or the like.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  5. #5
    Registered User HelpfulPerson's Avatar
    Join Date
    Jun 2013
    Location
    Over the rainbow
    Posts
    288
    Quote Originally Posted by grumpy View Post
    If your program (or process) attempts to go over a quota, it would typically not be allowed to start - the process of launching the executable would fail. Some program launchers would adjust quotas and make subsequent attempts to re-launch, but those sorts of things are unusual.

    From a basic architectural perspective, I'd query why your program needs to keep all its data in a global structure in the first place. Such techniques implicitly limit the ability of a program to evolve, usually before any problems with stack quota or the like.
    Well it's easier than having to keep track of a lot of data for each function separately. Most of the biggest pieces of data are dynamically allocated in linked lists and the sort though.
    "Some people think they can outsmart me, maybe. Maybe. I've yet to meet one that can outsmart bullet" - Meet the Heavy, Team Fortress 2

  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by HelpfulPerson View Post
    Well it's easier than having to keep track of a lot of data for each function separately.
    That's the common rationale employed. The headaches come later .....
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  7. #7
    Registered User
    Join Date
    Apr 2013
    Posts
    1,646
    Most compilers have a compile time option to set the stack size.

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Firstly, a description of this kind has nothing to do with the stack: "consistently that seems to grow exponentially by the day".
    That's a rough description of a memory leak, which would no doubt involve heap memory.
    Don't go throwing in buzzwords like "exponentially" which is almost certainly untrue in this case. More plausibly it grows somewhat "linearly".

    Most importantly though, how did you measure this? I'm guessing Task Manager? I'll let you in on a well-known fact... Task Manager doesn't actually give you anything that is a good measure of how much memory is taken up by your application. As a developer, you need to be using "Process Explorer" from Windows Sysinternals: Documentation, downloads and additional resources. No Windows developer should be without it.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #9
    Registered User
    Join Date
    Apr 2013
    Posts
    1,646
    Quote Originally Posted by HelpfulPerson View Post
    I have a structure ... that seems to grow exponentially by the day.
    Quote Originally Posted by iMalc View Post
    "consistently that seems to grow exponentially by the day". ... That's a rough description of a memory leak.
    I think he means that some structure is growing day by day.

    Stack space is pre-allocated at run time before main is called. On some operating systems / compilers it's possible to increase the size of the stack, but typically if a "non-standard" stack size is needed, it's done via a compile time option.

    If there is only a single instance of this structure in main(), an alternative to using stack space is to declare the structure "static", so that it's pre-allocated and initialized in the same area as global variables, often called the "data segment". It won't be using stack space, but it will still use memory space, so it's possible that the program could run out of memory at run time if the program is also allocating memory (such as malloc()).

  10. #10
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    If you were that worried, you'd just make it a malloc'd variable. It literally takes a handful of lines of code and ensures that - if the machine has enough RAM - you'll always have enough space for it.

    Those people who worry about the stack-size don't see that the end solution is to either static it or malloc it, and both end up taking from global heap rather than the stack. Why worry about it when you could just have malloc'd it in the first place (and then even stood a chance of erroring out nicely if you were running in some ridiculously-low-memory environment that can't even do that allocation)?

    If stack space worries you, at all, in any way, in even a "well, in the future" kind of way - don't use it. Just malloc stuff instead. What do you lose? Nothing.

    If you ever hit stack limits, there is very little you can do anyway - as pointed out you can change the size of the stack but that makes your code hard to port (do you know how to change stack size on every type of compiler / machine and put it in your Makefiles?) and still doesn't guarantee that it will even do anything (some machines, you can't change the stack size to an arbitrary value and so it will just override you anyway). So pre-empt hitting them and the second you think to yourself "Wow, that's getting large", stop allocating it from the stack.

    I can't say I've ever written a program that hit a stack limit except on Palm handhelds (some of which had ludicrously limited stacks and horrendous compiler workarounds to get around them), and that used so little stack that I never even thought it would be a problem, it wasn't a problem on ANY other kind of machine, and in the end I just restructured stuff to be dynamic as much as possible.

    Don't worry about it. When you do need to worry about it, you have to do the EXACT thing that you're trying to avoid - make the allocations not come from the stack but from the heap. So pre-empt it and just allocate it from the heap now and save yourself the effort of even counting up how many bytes it would take on the stack.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  11. #11
    Registered User HelpfulPerson's Avatar
    Join Date
    Jun 2013
    Location
    Over the rainbow
    Posts
    288
    Quote Originally Posted by ledow View Post
    If you were that worried, you'd just make it a malloc'd variable. It literally takes a handful of lines of code and ensures that - if the machine has enough RAM - you'll always have enough space for it.
    I thought about that later, that I could just create the structure as a single node on the heap just as easily. It wouldn't really change how I declare it, except I would have to add a handful of lines to handle allocating it. Then pass the structure as a pointer to the structure to the rest of the functions as needed, just as I have been doing.

    Quote Originally Posted by rcgldr View Post
    I think he means that some structure is growing day by day.
    That's what I meant. As far as using task manager goes, I do use it for rough estimates from time to time. I assumed it only took into account heap memory though, as I observed it going up and down in tune to malloc() and free() calls. If it doesn't give me the data I think it does, I would be glad to use another( preferably free ) software to use as a developer. Also, as far as the word exponentially goes, I'm sorry if it was taken the wrong way. I was just using that word to describe how the structure is rapidly growing when I add new features.
    "Some people think they can outsmart me, maybe. Maybe. I've yet to meet one that can outsmart bullet" - Meet the Heavy, Team Fortress 2

  12. #12
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by HelpfulPerson View Post
    As far as using task manager goes, I do use it for rough estimates from time to time. I assumed it only took into account heap memory though, as I observed it going up and down in tune to malloc() and free() calls. If it doesn't give me the data I think it does, I would be glad to use another( preferably free ) software to use as a developer. Also, as far as the word exponentially goes, I'm sorry if it was taken the wrong way. I was just using that word to describe how the structure is rapidly growing when I add new features.
    Task Manager more or less shows you how much of the application's memory space is not currently paged out to disk. When you malloc memory, and thereafter use it, the OS caching usually wont chuck it straight out to the page file, and when you free, the C runtime might sometimes give some blocks back to the OS. It's all very rough and typically nowhere near reliable enough for leak detection.
    Its going up or down often says more about the rest of the stuff running on the PC than what your app is using.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by ledow View Post
    If stack space worries you, at all, in any way, in even a "well, in the future" kind of way - don't use it. Just malloc stuff instead. What do you lose? Nothing.
    Absolutely everything. Especially in C.
    Heap memory isn't free. It costs more to allocate small chunks to overhead and most important, you have to free it! None of this applies to stack variables.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 3
    Last Post: 11-20-2011, 12:01 AM
  2. Is there a limit to the size of 2-D arrays?
    By ashley in forum C Programming
    Replies: 2
    Last Post: 01-04-2007, 04:01 PM
  3. Want a C Function to get current thread's stack size
    By m.sudhakar in forum C Programming
    Replies: 6
    Last Post: 07-31-2006, 12:18 PM
  4. Message box as thread to stop main thread
    By Yasir_Malik in forum Windows Programming
    Replies: 8
    Last Post: 04-11-2006, 11:07 AM
  5. std::getline size limit
    By dirkduck in forum C++ Programming
    Replies: 4
    Last Post: 07-23-2003, 03:11 PM