20

Is there a limit on the stack size of a process in Linux? Is it simply dependent on the RAM of the machine?

I want to know this in order to limit the depth of recursive calls to a function.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
michael
  • 106,540
  • 116
  • 246
  • 346
  • you can always throw together a quick test to see how deep the stack is. CountDepth(int d) { CountDepth(d + 1); } – Martin Apr 17 '10 at 00:21
  • 2
    @Martin: Though the "depth" lowers when you actually do something in the function, with variables. – GManNickG Apr 17 '10 at 00:25
  • that's true, but it's a good estimate. if you really wanted you could count the number of bits in use in temporary variables and method parameters and work it out exactly for a given function – Martin Apr 17 '10 at 02:55

4 Answers4

34

The stack is normally limited by a resource limit. You can see what the default settings are on your installation using ulimit -a:

stack size              (kbytes, -s) 8192

(this shows that mine is 8MB, which is huge).

If you remove or increase that limit, you still won't be able to use all the RAM in the machine for the stack - the stack grows downward from a point near the top of your process's address space, and at some point it will run into your code, heap or loaded libraries.

caf
  • 233,326
  • 40
  • 323
  • 462
  • 2
    "at some point it will run into your code, heap or loaded libraries" I doubt whether that would be a problem on 64-bit systems such as Linux x86_64? – Sam Watkins Feb 06 '15 at 01:51
  • 1
    @SamWatkins: Right - this answer was written 5 years ago, and was in the context of 32 bit environments. – caf Feb 06 '15 at 11:24
  • This is incorrect for `i386` if [its ABI](http://www.sco.com/developers/devspecs/abi386-4.pdf) is to be believed. In it, stack is located under everything else and can theoretically grow to a bit over `128MiB`. In [`AMD64` ABI](https://www.uclibc.org/docs/psABI-x86_64.pdf), it grows from under the `128GiB` mark, just under shared libraries. So it can theoretically overwrite code/data, but only of the main program or its heap. – ivan_pozdeev Sep 25 '16 at 21:06
  • 1
    @ivan_pozdeev: Stack is last on Linux - check `/proc//maps` on an x86 Linux installation. See for example [this commit message](https://lwn.net/Articles/90311/) that describes a new layout implemented back in 2004 - both the old and new layouts had the stack last. – caf Sep 27 '16 at 05:41
6

The limit can be set by the admin.

See man ulimit.

There is probably a default which you cannot cross. If you have to worry about stack limits, I would say you need to rethink your design, perhaps write an iterative version?

5

It largely depends what architecture you're on (32 or 64-bit) and whether you're multithreaded or not.

By default in a single threaded process, i.e. the main thread created by the OS at exec() time, your stack usually will grow until it hits something else in the address space. This means that it is generally possible, on a 32-bit machine, to have, say 1G of stack.

However, this is definitely NOT the case in a multithreaded 32-bit process. In multithreaded procesess, the stacks share address space and hence need to be allocated, so they typically get given a small amount of address space (e.g. 1M) so that many threads can be created without exhausting address space.

So in a multithreaded process, it's small and finite, in a single threaded one, it's basically until you hit something else in the address-space (which the default allocation mechanism tries to ensure doesn't happen too soon).

In a 64-bit machine, of course there is a lot more address space to play with.

In any case you can always run out of virtual memory, in which case you'll get a SIGBUS or SIGSEGV or something.

MarkR
  • 62,604
  • 14
  • 116
  • 151
1

Would have commented on the accepted answer but apparently I need more rep....

True Stack Overflow can be subtle and not always cause any error messages or warnings. I just had a situation where the only symptom was that socket connections would fail with strange SSL errors. Everything else worked fine. Threads could malloc(), grab locks, talk to the DB, etc. But new connections would fail at the SSL layer.

With stack traces from well within GnuTLS I was quite confused about the true cause. Nearly reported the traces to their team after spending lots of time trying to figure it out.

Eventually found that the stacksize was set to 8Mb and immediately upon raising it the problems vanished. Lowering the stack back to 8Mb brought the problem back (ABA).

So if you are troubleshooting what appears to be strange socket errors without any other warnings or uninitialized memory errors.... it could be stack overflow.

AcidTonic
  • 171
  • 1
  • 7
  • 3
    Shouldn't the stack be followed by unmapped / unwritable blocks (above and below), to prevent such carnage? If I am correct, how can a stack overflow then not cause a SEGV or similar fault? I suggest that the cause of your bug might have been something else, and the stack change fixed it by coincidence (quasi-heisenbug). – Sam Watkins Feb 06 '15 at 01:52
  • Sorry for the late reply, it depends on the OS guard page layout and behavior of the overflow. If you overflow the stack in specific ways you will not get a segfault. Some older platforms didn't use guard pages or if so didn't place them in the same places as is done today. The segfault is still something that might not occur depending on how the stars align in that particular situation. – AcidTonic Apr 04 '18 at 17:57
  • @SamWatkins: a large enough `alloca` or C99 VLA can skip past a guard page, and into another region. (This is a stack clash attack, if done maliciously into a program that doesn't sanity check sizes before using local arrays. See [Linux process stack overrun by local variables (stack guarding)](https://stackoverflow.com/q/60058873) for more about compiler options for hardening against that, e.g. via stack probes to make sure intervening pages are touched when growing the stack by more than a page, even on Linux which doesn't require that.) – Peter Cordes Jan 10 '22 at 18:41
  • Also [Stack Guard and Stack Smashing Protection - canaries, memory](https://stackoverflow.com/q/28020213). But yeah, there should be guard pages below the stack to catch any "innocent" stack overflows. Maybe on a 32-bit system with its cramped virtual address space, there might end up being something right below a thread stack. Should be a non-issue on 64-bit systems, especially for the main thread. – Peter Cordes Jan 10 '22 at 18:43