Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 3 down vote favorite

getrlimit(2) has the following definition in the man pages:

RLIMIT_AS The maximum size of the process's virtual memory (address space) in bytes. This limit affects calls to brk(2), mmap(2) and mremap(2), which fail with the error ENOMEM upon exceeding this limit. Also automatic stack expansion will fail (and generate a SIGSEGV that kills the process if no alternate stack has been made available via sigaltstack(2)). Since the value is a long, on machines with a 32-bit long either this limit is at most 2 GiB, or this resource is unlimited.

What is meant by "automatic stack expansion" here? Does the stack in a Linux/UNIX environment grow as needed? If yes, what's the exact mechanism?

share|improve this question

1 Answer

up vote 1 down vote accepted

Yes stacks grow dynamically. The stack is in the top of the memory growing downwards towards the heap.

--------------
| Stack      |
--------------
| Free memory|
--------------
| Heap       |
--------------
     .
     .

The heap grows upwards (whenever you do malloc) and the stack grows downwards as and when new functions are called. The heap is present just above the BSS section of the program. Which means the size of your program and the way it allcates memory in heap also affect the maximum stack size for that process. Usually the stack size is unlimited (till heap and stack areas meet and/or overwrite which will give a stack overflow and SIGSEGV :-)

This is only for the user processes, The kernel stack is fixed always (usually 8KB)

share|improve this answer
"Usually the stack size is unlimited", no, usually it limited by 8Mb (ulimit -s). – Eddy_Em Feb 5 at 6:57
yes you are right in most systems. You are checking the shell's ulimit command, if so there is a hard limit on the stack size, which is unlimited (ulimit -Hs). Anyway, that point was to stress that stack and heap grows in the opposite directions. – Santosh Feb 5 at 9:53
Then how is "automatic expansion" is any different from "pushing elements to the stack"? From your explanation, I get the feeling that they are the same. Also, I felt like starting points of stack and heap are way more than 8MB, so the stack can grow as much as it need (or it hits the heap). Is that true? If yes, how does the operating system decided on where to place the heap and the stack? – loudandclear Feb 5 at 15:21
They are the same, but stacks dont have a fixed size unless you hard limit the size using rlimit. Stack is placed at the end of the virtual memory area, and heap is immediatly af*er tke data segment of the executable. – Santosh Feb 5 at 21:57
I understand, thanks. However, I don't think I get the "stacks don't have fixed size" part. If that's the case, what's the 8Mb soft limit for? – loudandclear Feb 6 at 16:43
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.