Take the 2-minute tour ×
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.

Does the OS reserve the fixed amount of valid virtual space for stack or something else? Am I able to produce a stack overflow just by using big local variables?

I've wrote a small C program to test my assumption. It's running on X86-64 CentOS 6.5.

#include <string.h>
#include <stdio.h>
int main()
{
    int n = 10240 * 1024;
    char a[n];
    memset(a, 'x', n);
    printf("%x\n%x\n", &a[0], &a[n-1]);
    getchar();
    return 0;
}

Running the program gives &a[0] = f0ceabe0 and &a[n-1] = f16eabdf

The proc maps shows the stack: 7ffff0cea000-7ffff16ec000. (10248 * 1024B)

Then I tried to increase n = 11240 * 1024

Running the program gives &a[0] = b6b36690 and &a[n-1] = b763068f

The proc maps shows the stack: 7fffb6b35000-7fffb7633000. (11256 * 1024B)

ulimit -s prints 10240 in my PC.

As you can see, in both case the stack size is bigger than which ulimit -s gives. And the stack grows with bigger local variable. The top of stack is somehow 3-5kB more off &a[0] (AFAIK the red zone is 128B).

So how does this stack map get allocated?

share|improve this question

2 Answers 2

up vote 6 down vote accepted

It appears that the stack memory limit is not allocated (anyway, it couldn't with unlimited stack). https://www.kernel.org/doc/Documentation/vm/overcommit-accounting says:

The C language stack growth does an implicit mremap. If you want absolute guarantees and run close to the edge you MUST mmap your stack for the largest size you think you will need. For typical stack usage this does not matter much but it's a corner case if you really really care

However mmapping the stack would be the goal of a compiler (if it has an option for that).

EDIT: After some tests on an x84_64 Debian machine, I've found that the stack grows without any system call (according to strace). So, this means that the kernel grows it automatically (this is what the "implicit" means above), i.e. without explicit mmap/mremap from the process.

It was quite hard to find detailed information confirming this. I recommend Understanding The Linux Virtual Memory Manager by Mel Gorman. I suppose that the answer is in 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.

Other references about Linux memory management (but with almost nothing about the stack):

EDIT 2: This implementation has a drawback: in corner cases, a stack-heap collision may not be detected, even in the case where the stack would be larger than the limit! The reason is that a write in a variable in the stack may end up in allocated heap memory, in which case there is no page fault and the kernel cannot know that the stack needed to be extended. See my example in the discussion Silent stack-heap collision under GNU/Linux I started in the gcc-help list. To avoid that, the compiler needs to add some code at function call; this can be done with -fstack-check for GCC (see Ian Lance Taylor's reply and the GCC man page for details).

share|improve this answer
    
That seems the correct answer to my question. But it confuses me more. When will the mremap call get triggered? Will it be a syscall built into the program? –  amos Jul 20 at 11:19
    
@amos I assume that the mremap call will be triggered if need be at a function call or when alloca() is called. –  vinc17 Jul 20 at 11:22
    
It would probably be a good idea to mention what mmap is, for people who don't know. –  Faheem Mitha Jul 20 at 13:35
    
@FaheemMitha I've added some information. For those who don't know what mmap is, see the memory FAQ mentioned above. Here, for the stack, it would have been "anonymous mapping" so that unused space wouldn't take any physical memory, but as explained by Mel Gorman, the kernel does the mapping (virtual memory) and the physical allocation at the same time. –  vinc17 Jul 20 at 14:42

By default, the maximal stack size is configured to be 8MB per process,
but it can be changed using ulimit:

Showing the default in kB:

$ ulimit -s
8192

Set to unlimited:

ulimit -s unlimited

affecting the current shell and subshells and their child processes.
(ulimit is a shell builtin command)

You can show the actual stack address range in use with:
cat /proc/$PID/maps | grep -F '[stack]'
on Linux.

share|improve this answer
    
So when a program is loaded by the current shell, OS will make a memory segment of ulimit -sKB valid for the program. In my case it's 10240KB. But when I declare a local array char a[10240*1024] and set a[0]=1, the program exits correctly. Why? –  amos Jul 20 at 10:27
    
Try to set the last element too. And make sure that they are not optimized away. –  vinc17 Jul 20 at 10:34
    
@amos I think what vinc17 means is that you named a memory region that would not fit on the stack in your program, but as you do not actually access it in the part that does not fit, the machine never notices that - it does not even get that information. –  Volker Siegel Jul 20 at 10:56
    
@amos Try int n = 10240*1024; char a[n]; memset(a,'x',n); ...seg fault. –  goldilocks Jul 20 at 11:05
2  
@amos So, as you can see, a[] has not been allocated in your 10MB stack. The compiler might have seen that there couldn't be a recursive call and has done special allocation, or something else like a discontinuous stack or some indirection. –  vinc17 Jul 20 at 12:20

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.