blocks|key|3074719|text|C%2B%2B是一种强大的语言，随之而来的是搬起石头砸自己的脚的能力。我不知道有什么便携机制可以在发生堆栈溢出时检测和纠正/中止。当然，任何这样的检测都是特定于实现的。例如，g%2B%2B提供了-fstack-protector来帮助监控堆栈使用情况。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3074720|一般来说，您最好的办法是主动避免大型基于堆栈的变量，并小心处理递归调用。|3074721|entityMap^0|2H|H|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

C++ is a powerful language, and with that power comes the ability to shoot yourself in the foot. I'm not aware of any portable mechanism to detect and correct/abort when stack overflow occurs. Certainly any such detection would be implementation-specific. For example g++ provides <code>-fstack-protector</code> to help monitor your stack usage.

In general your best bet is to be proactive in avoiding large stack-based variables and careful with recursive calls.

blocks|key|3074760|text|您可以使用良好的编程实践来防止堆栈溢出，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3074761|3074762|对递归非常小心，我最近看到一个由于写得不好的递归CreateDirectory函数导致的错误，如果你不确定你的代码是否100%25+ok，那么添加保护变量，它将在N个递归调用后停止执行。或者更好的是不要写递归函数。|ordered-list-item|3074763|不会在堆栈上创建巨大的数组，这可能是隐藏的数组，比如一个非常大的数组作为类字段。使用向量总是更好。|3074764|在使用alloca时要非常小心，特别是当它被放入一些宏定义时。我见过许多这样的结果，字符串转换宏放入循环，使用alloca的快速内存allocations.|3074765|Make确保您的堆栈大小是最佳的，这是更重要的嵌入式平台。如果你的线程做的不多，那么给它小的堆栈，否则使用更大的堆栈。我知道预留应该只占用一些地址范围，而不是物理内存。|3074766|3074767|这些是我在过去几年中见过的最多的原因。|3074768|对于自动查找SO，您应该能够找到一些静态代码分析工具。|3074769|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|X|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

You can protect against stack overflows using good programming practices, like:

<ol>
<li>Be very carefull with recursion, I have recently seen a SO resulting from badly written recursive CreateDirectory function, if you are not sure if your code is 100% ok, then add guarding variable that will stop execution after N recursive calls. Or even better dont write recursive functions.</li>
<li>Do not create huge arrays on stack, this might be hidden arrays like a very big array as a class field. Its always better to use vector.</li>
<li>Be very carefull with alloca, especially if it is put into some macro definition. I have seen numerous SO resulting from string conversion macros put into for loops that were using alloca for fast memory allocations.</li>
<li>Make sure your stack size is optimal, this is more important in embeded platforms. If you thread does not do much, then give it small stack, otherwise use larger. I know reservation should only take some address range - not physical memory.</li>
</ol>

those are the most SO causes I have seen in past few years.

For automatic SO finding you should be able to find some static code analysis tools.

blocks|key|215928|text|Re:可扩展堆栈。你可以像这样给你自己更多的堆栈空间：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|215929|#include+<iostream>

int+main()
{
++++int+sp=0;

++++//+you+probably+want+this+a+lot+larger
++++int+*mystack+=+new+int[64*1024];
++++int+*top+=+(mystack+%2B+64*1024);

++++//+Save+SP+and+set+SP+to+our+newly+created
++++//+stack+frame
++++__asm__+(+
++++++++"mov+%25%25esp,%25%25eax;+mov+%25%25ebx,%25%25esp":
++++++++"=a"(sp)
++++++++:"b"(top)
++++++++:
++++++++);
++++std::cout+<<+"sp="+<<+sp+<<+std::endl;

++++//+call+bad+code+here

++++//+restore+old+SP+so+we+can+return+to+OS
++++__asm__(
++++++++"mov+%25%25eax,%25%25esp":
++++++++:
++++++++"a"(sp)
++++++++:);

++++std::cout+<<+"Done."+<<+std::endl;

++++delete+[]+mystack;
++++return+0;
}|code-block|syntax|javascript|215930|这是gcc的汇编语法。|215931|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Re: expandable stacks. You could give yourself more stack space with something like this:

<pre><code>#include &lt;iostream&gt;

int main()
{
 int sp=0;

 // you probably want this a lot larger
 int *mystack = new int[64*1024];
 int *top = (mystack + 64*1024);

 // Save SP and set SP to our newly created
 // stack frame
 __asm__ ( 
 "mov %%esp,%%eax; mov %%ebx,%%esp":
 "=a"(sp)
 :"b"(top)
 :
 );
 std::cout &lt;&lt; "sp=" &lt;&lt; sp &lt;&lt; std::endl;

 // call bad code here

 // restore old SP so we can return to OS
 __asm__(
 "mov %%eax,%%esp":
 :
 "a"(sp)
 :);

 std::cout &lt;&lt; "Done." &lt;&lt; std::endl;

 delete [] mystack;
 return 0;
}
</code></pre>

This is gcc's assembler syntax.

blocks|key|216211|text|我不认为那是可行的。最好是push/pop，而不是移到一个寄存器，因为你不知道编译器是否会决定使用eax来做一些事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|216212|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't think that that would work. It would be better to push/pop esp than move to a register because you don't know if the compiler will decide to use eax for something.

blocks|key|2861316|text|给你：https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/resetstkoflw?view=msvc-160|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2861317|2861318|你不会自己捕捉到EXCEPTION_STACK_OVERFLOW结构化异常，因为操作系统会捕捉到它(在Windows的例子中)。|ordered-list-item|2861319|是的，你可以安全地从不同于上面所指出的结构化异常(称为“异步”)中恢复。如果不能，Windows将根本无法工作。PAGE_FAULTs是结构化异常，可从中恢复。|2861320|2861321|我不太熟悉Linux和其他平台上的工作原理。|2861322|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/resetstkoflw?view=msvc-160^0|3|2J|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

Here ya go:
<a href="https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/resetstkoflw?view=msvc-160" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/resetstkoflw?view=msvc-160</a>
<ol>
<li>You wouldn't catch the EXCEPTION_STACK_OVERFLOW structured exception yourself because the OS is going to catch it (in Windows' case).</li>
<li>Yes, you can safely recover from an structured exception (called &quot;asynchronous&quot; above) unlike what was indicated above. Windows wouldn't work at all if you couldn't. PAGE_FAULTs are structured exceptions that are recovered from.</li>
</ol>
I am not as familiar with how things work under Linux and other platforms.

In C++ a stack overflow usually leads to an unrecoverable crash of the program. For programs that need to be really robust, this is an unacceptable behaviour, particularly because stack size is limited. A few questions about how to handle the problem. 

<ol>
<li>Is there a way to prevent stack overflow by a general technique. (A scalable, robust solution, that includes dealing with external libraries eating a lot of stack, etc.)</li>
<li>Is there a way to handle stack overflows in case they occur? Preferably, the stack gets unwound until there's a handler to deal with that kinda issue. </li>
<li>There are languages out there, that have threads with expandable stacks. Is something like that possible in C++?</li>
</ol>

Any other helpful comments on the solution of the C++ behaviour would be appreciated.

How to handle or avoid a stack overflow in C++

代码分析工具

静态代码分析

编译器

Windows

Linux

在C++中，堆栈溢出通常会导致程序不可恢复的崩溃。对于需要真正健壮的程序，这是不可接受的行为，特别是因为堆栈大小是有限的。关于如何处理这个问题的几个问题。提供了一种通用技术来防止堆栈溢出。(一个可伸缩的、健壮的解决方案，包括处理外部库吞噬大量堆栈等)有没有办法在堆栈溢出发生的情况下进行处理？最好的情况是，在有处理程序来...

问如何处理或避免C++中的堆栈溢出
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理或避免C++中的堆栈溢出EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理或避免C++中的堆栈溢出
EN