Where is the stack memory allocated from for a Linux process?
We know that when a process is created,one stack is allocated for this process.The size of the stack is typically 8 Mb in linux.My question is that,from where this stack is allocated??From user space or from system space?
4 Answers 4
I hope you know the concept that all user process will be kept in user space only. It uses system calls to get some work done by kernel.
The stack memory will be part of process context area in memory. i.e user space.
Suppose your process is running, get the PID by ps -ax . say 1234 is your PID.
cat /proc/1234/maps will give you the mapping of that particular process.
In thats maps file, you can check the stack for stack mapping.
your answer gives great insight as I was not aware of these. I have a small clarification.. How does the stack size is decided (we typically say 8 mb) ? Is it always 8mb?
But when one process comes in existence then one kernel stack is allotted for it.So this process stack and kernel stack are same or different?
First you must understand what paging and page faults are: How does x86 paging work?
Kernel vs process memory
The Linux Kernel reserves two zones of virtual memory:
The exact split is configured by CONFIG_VMSPLIT_. . By default:
- on 32-bit:
- the bottom 3/4 is program space: 00000000 to BFFFFFFF
- the top 1/4 is kernel memory: C0000000 to FFFFFFFF
------------------ FFFFFFFF Kernel ------------------ C0000000 ------------------ BFFFFFFF Process ------------------ 00000000- the bottom part to processes 00000000 00000000 to 008FFFFF FFFFFFFF
- the top part to the kernel: FFFF8000 00000000 to FFFFFFFF FFFFFFFF
------------------ FFFFFFFF FFFFFFFF Kernel ------------------ FFFF8000 00000000 (not addressable) ------------------ 008FFFFF FFFFFFFF Process ------------------ 00000000 00000000Process address space
Simplified program virtual memory of a process:
Stack allocation
The kernel maintains a list of pages that belong to each process, and synchronizes that with the paging.
If the program accesses memory that does not belong to it, the kernel handles a page-fault, and decides what to do:
- if it is above the maximum stack size, allocate those pages to the process
- otherwise, send a SIGSEGV to the process, which usually kills it
brk and mmap
Those system calls allow processes to explicitly request chunks of memory to the kernel instead of just going down the stack and segfaulting.
Here is a practical example of brk : What does brk( ) system call do?
This answer explains the advantage of using the stack when that is possible: What is the function of the push / pop instructions used on registers in x86 assembly?
Physical memory
As others said, the stack is allocated in user space. But here are more details about this, in particular about its size and its growth.
8 MB is actually not the stack size, but the maximum stack size. A small part is initially allocated and the kernel grows the stack automatically when needed (after a page fault), keeping it below the stack size limit. If you do a memory access above the limit, you’ll get a segmentation fault. But even if you do not reach this limit, this means that you might exhaust the physical memory (RAM + swap) just by filling the stack.
Here’s a reference I’ve given in my answer to How does stack allocation work in Linux?: Mel Gorman’s paper Understanding The Linux Virtual Memory Manager. See in particular Section 4.6.1 Handling a Page Fault, with the exception «Region not valid but is beside an expandable region like the stack» and the corresponding action «Expand the region and allocate a page». See also D.5.2 Expanding the Stack.
How to determine Stack size of a Program in linux?
How does one determine the current stack size of a program in linux? it is said that the stack size of each program will be 8 MB in linux but when you use cat /proc//mmap it shows a different size. Also, how does one determine stack size of associated threads? Since it is said that threads have their own private stack?
3 Answers 3
If you simply want the current stack size, you could declare a variable at the top of main(), take its address, and compare it to the address of a variable declared at wherever you define «current» to be. The difference should be the approximate size that the stack has grown.
If you want to know how much memory is reserved for the stack, you can check /proc/[pid]/maps, which has a region marked as [stack]. For example, my atd process has:
7fff72a41000-7fff72a56000 rw-p 00000000 00:00 0 [stack] 0175b000-0177c000 rw-p 00000000 00:00 0 [heap]A neat trick that a friend shared with me when I wanted to know the maximum size of stack that my program used was as follows. I’ll present it here in case someone finds it useful 🙂
1) In a function called near the beginning of main(), use alloca() or a very long array to scribble 0xDEADBEEF or some other such unlikely constant over as much of the stack as you expect could be used. This memory will be «freed» when the small function returns.
2) At the end of main, again use alloca() to grab a region of memory and «search» down through it for whatever magic constant you used to scribble (you might try to find the first block of 64 of them or something to skip over regions of memory that may have been allocated but simply never used), and where that pointer lands indicates your maximum stack usage.
Not perfect, but it was useful for what I was doing!
How to measure the stack size of a process?
How do I find the stack size of a process ? /proc/5848/status gives me VmStk but this doesnt change No matter how much ever while loop and recursion I do in my test program this value hardly changes. when I looked at /proc/pid/status all of the process has 136k and have no idea where that value comes from. Thanks,
3 Answers 3
There really is no such thing as the «stack size of a process» on Linux. Processes have a starting stack, but as you see, they rarely allocate much from the standard stack. Instead, processes just allocate generic memory from the operating system and use it as a stack. So there’s no way for the OS to know — that detail is only visible from inside the process.
A typical, modern OS may have a stack size limit of 8MB imposed by the operating system. Yet processes routinely allocate much larger objects on their stack. That’s because the application is using a stack that is purely application-managed and not a stack as far as the OS is concerned.
This is always true for multi-threaded processes. For single-threaded processes, it’s possible they are actually just using very, very little stack.
Thanks for the answer, could you please provide examples of languages that still use stack for keeping local variables? (instead of emulating stack with heap).
@VitalyIsaev I don’t think that’s likely to be a property of a language. For example, C and C++ programs used to just use the stack for everything a few decades ago. It’s more likely to be an implementation property based on the size and complexity of the machine. Essentially, programs have «outgrown» using a single stack provided by the process startup mechanism.
Is there a limit of stack size of a process in linux
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.
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
4 Answers 4
The stack is normally limited by a resource limit. You can see what the default settings are on your installation using ulimit -a :
(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.
«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?
@SamWatkins: Right — this answer was written 5 years ago, and was in the context of 32 bit environments.
This is incorrect for i386 if its ABI is to be believed. In it, stack is located under everything else and can theoretically grow to a bit over 128MiB . In AMD64 ABI, 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: Stack is last on Linux — check /proc/
/maps on an x86 Linux installation. See for example this commit message that describes a new layout implemented back in 2004 — both the old and new layouts had the stack last. The limit can be set by the admin.
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?
Or just write a recursive version that uses a manually managed stack instead of the function call stack.
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.
Linux Stack Sizes
I’m looking for a good description of stacks within the linux kernel, but I’m finding it surprisingly difficult to find anything useful. I know that stacks are limited to 4k for most systems, and 8k for others. I’m assuming that each kernel thread / bottom half has its own stack. I’ve also heard that if an interrupt goes off, it uses the current thread’s stack, but I can’t find any documentation on any of this. What I’m looking for is how the stacks are allocated, if there’s any good debugging routines for them (I’m suspecting a stack overflow for a particular problem, and I’d like to know if its possible to compile the kernel to police stack sizes, etc).
what kernel version are you working with? so we have a better idea of the kernel debug configuration options available to you.
«bottom-halves» probably share the same stack. Also, «bottom-halves» disappeared a long time ago, now there are softirqs left.
3 Answers 3
The reason that documentation is scarce is that it’s an area that’s quite architecture-dependent. The code is really the best documentation — for example, the THREAD_SIZE macro defines the (architecture-dependent) per-thread kernel stack size.
The stacks are allocated in alloc_thread_stack_node() . The stack pointer in the struct task_struct is updated in dup_task_struct() , which is called as part of cloning a thread.
The kernel does check for kernel stack overflows, by placing a canary value STACK_END_MAGIC at the end of the stack. In the page fault handler, if a fault in kernel space occurs this canary is checked — see for example the x86 fault handler which prints the message Thread overran stack, or stack corrupted after the Oops message if the stack canary has been clobbered.
Of course this won’t trigger on all stack overruns, only the ones that clobber the stack canary. However, you should always be able to tell from the Oops output if you’ve suffered a stack overrun — that’s the case if the stack pointer is below task->stack .