问题描述
在多线程嵌入式软件（用C或C ++编写）中，线程必须有足够的堆栈空间，以使其能够完成其操作而不会溢出。在某些实时嵌入式环境中，正确的堆栈大小至关重要，因为（至少在某些我曾经使用过的系统中），操作系统将无法检测到这个。
通常，在创建线程时（即在pthread_create（）的参数等）中指定新线程（主线程除外）的堆栈大小。通常，这些堆栈大小被硬编码为在代码原始编写或测试时已知的值。
然而，将来的代码更改经常打破硬编码堆栈大小所基于的假设，一个命运的一天，你的线程进入其调用图的更深的分支之一并溢出堆栈 - 使整个系统或静默地破坏内存。 p>
在线程中执行的代码声明堆栈上的结构体实例的情况下，我亲眼目睹了这个问题。当结构体被增加以保存附加数据时，堆栈大小相应地膨胀，潜在地允许堆栈溢出发生。我想象这对于已经建立的代码库来说可能是一个巨大的问题，其中添加字段到结构的全部效果不能被立即知道（太多的线程/函数找到使用该结构的所有位置）。
由于对堆栈大小问题的通常响应是它们不可移植，我们假设编译器，操作系统和处理器都是此调查的已知数量。我们还假设递归没有被使用，所以我们不会处理无限递归的可能性。
什么是一些可靠的方法来估计必要的堆栈一个线程的大小？我喜欢离线（静态分析）和自动的方法，但所有想法都是受欢迎的。
运行时 - 评估
一种在线方法是使用一定的值绘制完整的堆栈，如0xAAAA（或0xAA，无论您的宽度是多少）。然后，您可以通过查看多少绘画保持原样来检查堆栈的最大增长程度。
看看链接，以说明说明。
优点是简单。缺点是您无法确定您的堆栈大小最终不会超过测试期间使用的堆栈数量。
静态评估
有一些静态检查，我认为甚至存在一个被破解的gcc版本，试图这样做。我唯一可以告诉你的是，在一般情况下，静态检查是非常困难的。
另外看一下问题。
In multi-threaded embedded software (written in C or C++), a thread must be given enough stack space in order to allow it to complete its operations without overflowing. Correct sizing of the stack is critical in some real-time embedded environments, because (at least in some systems I've worked with), the operating system will NOT detect this for you.
Usually, the stack size for a new thread (other than the main thread) is designated at the time that thread is created (i.e. in an argument to pthread_create() or the like). Often, these stack sizes are hard-coded to values that are known to be good at the time the code was originally written or tested.
However, future changes to the code often break the assumptions on which the hard-coded stack sizes were based, and one fateful day, your thread enters one of the deeper branches of its call graph and overflows the stack -- bringing down the whole system or silently corrupting memory.
I have personally seen this problem in the case where code executed in the thread declares struct instances on the stack. When the struct is augmented to hold additional data, the stack size inflates accordingly, potentially allowing stack overflows to occur. I imagine this could be a huge problem for established codebases where the full effects of adding fields to a structure cannot be known immediately (too many threads/functions to find all the places where that struct is used).
Since the usual response to "stack sizing" questions is "they're not portable", let's assume that the compiler, operating system, and processor are all known quantities for this investigation. Let's also assume recursion isn't used, so we're not dealing with the possibility an "infinite recursion" scenario.
What are some reliable ways to estimate the necessary stack size for a thread? I'd prefer methods that are offline (static analysis) and automatic, but all ideas are welcome.
Runtime-Evaluation
An online method is to paint the complete stack with a certain value, like 0xAAAA (or 0xAA, whatever your width is). Then you can check how large the stack has maximally grown in the past by checking how much of the painting is left untouched.
Have a look at this link for an explanation with illustration.
The advantage is that it's simple. A disadvantage is that you cannot be certain that your stack size won't eventually exceed the amount of used stack during your testing.
Static Evaluation
There are some static checks and I think there even exists a hacked gcc version that tries to do this. The only thing I can tell you is that static checking is very difficult to do in the general case.
Also have a look at this question.
这篇关于堆栈大小估计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！