Linux “ulimit -s 无限制”有什么作用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14471564/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What does "ulimit -s unlimited" do?
提问by Brian Hawkins
There are understandably many related questions on stack allocation
可以理解，关于堆栈分配的相关问题很多
What and where are the stack and heap?
Why is there a limit on the stack size?
However on various *nix machines I can issue the bash command
但是在各种 *nix 机器上我可以发出 bash 命令
ulimit -s unlimited
or the csh command
或 csh 命令
set stacksize unlimited
How does this change how programs are executed? Are there any impacts on program or system performance (e.g., why wouldn't this be the default)?
这如何改变程序的执行方式？是否对程序或系统性能有任何影响（例如，为什么这不是默认设置）？
In case more system details are relevant, I'm mostly concerned with programs compiled with GCC on Linux running on x86_64 hardware.
如果需要更多系统细节，我最关心的是在 x86_64 硬件上运行的 Linux 上使用 GCC 编译的程序。
采纳答案by Alex
When you call a function, a new "namespace" is allocated on the stack. That's how functions can have local variables. As functions call functions, which in turn call functions, we keep allocating more and more space on the stack to maintain this deep hierarchy of namespaces.
当您调用函数时，会在堆栈上分配一个新的“命名空间”。这就是函数可以具有局部变量的方式。作为函数调用函数，函数又调用函数，我们不断在堆栈上分配越来越多的空间来维护这种深层次的命名空间。
To curb programs using massive amounts of stack space, a limit is usually put in place via ulimit -s. If we remove that limit via ulimit -s unlimited, our programs will be able to keep gobbling up RAM for their evergrowing stack until eventually the system runs out of memory entirely.
为了限制使用大量堆栈空间的程序，通常通过ulimit -s. 如果我们通过 删除该限制ulimit -s unlimited，我们的程序将能够继续为不断增长的堆栈占用 RAM，直到最终系统完全耗尽内存。
int eat_stack_space(void) { return eat_stack_space(); }
// If we compile this with no optimization and run it, our computer could crash.
Usually, using a ton of stack space is accidental or a symptom of very deep recursion that probably should not be relying so much on the stack. Thus the stack limit.
通常，使用大量堆栈空间是偶然的，或者是非常深的递归的症状，可能不应该如此依赖堆栈。因此堆栈限制。
Impact on performace is minor but does exist. Using the timecommand, I found that eliminating the stack limit increased performance by a few fractions of a second (at least on 64bit Ubuntu).
对性能的影响很小，但确实存在。使用该time命令，我发现消除堆栈限制可以将性能提高几分之一秒（至少在 64 位 Ubuntu 上）。
回答by favoretti
Mea culpa, stack size canindeed be unlimited. _STK_LIMis the default, _STK_LIM_MAXis something that differs per architecture, as can be seen from include/asm-generic/resource.h:
过失，堆栈大小可以确实是无限的。_STK_LIM是默认值，_STK_LIM_MAX每个架构都不同，从include/asm-generic/resource.h以下可以看出：
/*
* RLIMIT_STACK default maximum - some architectures override it:
*/
#ifndef _STK_LIM_MAX
# define _STK_LIM_MAX RLIM_INFINITY
#endif
As can be seen from this example generic value is infinite, where RLIM_INFINITYis, again, in generic case defined as:
从这个例子中可以看出，泛型值是无限的，其中RLIM_INFINITY又在泛型情况下定义为：
/*
* SuS says limits have to be unsigned.
* Which makes a ton more sense anyway.
*
* Some architectures override this (for compatibility reasons):
*/
#ifndef RLIM_INFINITY
# define RLIM_INFINITY (~0UL)
#endif
So I guess the real answer is - stack size CAN be limited by some architecture, then unlimited stack trace will mean whatever _STK_LIM_MAXis defined to, and in case it's infinity - it is infinite. For details on what it means to set it to infinite and what implications it might have, refer to the other answer, it's way better than mine.
所以我想真正的答案是 - 堆栈大小可以受某些架构的限制，然后无限的堆栈跟踪将意味着_STK_LIM_MAX定义的任何内容，如果它是无限的 - 它是无限的。有关将其设置为无限的含义以及它可能具有的含义的详细信息，请参阅另一个答案，它比我的要好得多。
回答by Abhishek Anand
"ulimit -s unlimited" lets the stack grow unlimited. This may prevent your program from crashing if you write programs by recursion, especially if your programs are not tail recursive (compilers can "optimize" those), and the depth of recursion is large.
“ulimit -s unlimited”让堆栈无限增长。如果您通过递归编写程序，这可能会防止您的程序崩溃，特别是如果您的程序不是尾递归的（编译器可以“优化”那些），并且递归深度很大。
The answer by @seisvelas almost contains the right answer to the question. However, it is buried deep in a multitude of false claims -- see the comments. Thus, I felt obligated to write this answer.
@seisvelas 的答案几乎包含了问题的正确答案。然而，它深藏在大量虚假声明中——见评论。因此，我觉得有义务写下这个答案。
