堆栈溢出异常，即使在增加堆栈大小后也是如此。 [英] Stack Overflow exception even after increasing the stack Size.

问题描述

我有一个C＃.net windows应用程序，我在x86模式下运行。它适用于x86模式。使用ANy CPU模式运行此应用程序时出现问题。我得到以下提到的错误：



XXXXXX.dll中发生未处理的System.StackOverflowException类型异常



我知道这可能是因为无限循环而且在这种情况下x86模式中应该发生同样的错误。我知道这不是因为无限次迭代。它与StackOverflow有关。



做了一些研究后，我改变了编辑箱中的堆栈大小，以便从



Editbin中增加它。 exe / Stack：14000000$（TargetDir）MyProject.exe



to



Editbin.exe / Stack：14000000$（TargetDir）MyProject.exe



有没有人有什么想法可能是什么原因以及我应该去哪些方向。？



非常感谢提前。



问候

目标

I have a C#.net windows application which I am running with x86 mode. It works great with x86 mode. the problem occurs when I run this application with ANy CPU mode. I get the below mentioned error:

An unhandled exception of type ''System.StackOverflowException'' occurred in XXXXXX.dll

I know this could be because of infinite loops and what not but the same error should occur in the x86 mode in that case. I know this is not because of infinite iterations. It has something to do with the StackOverflow.

After doing some research I changed the stack size in edit bin to increase it from

Editbin.exe /Stack:14000000 "$(TargetDir)MyProject.exe"

to

Editbin.exe /Stack:14000000 "$(TargetDir)MyProject.exe"

Does anyone have any Idea what could be the cause and what directions should I go in to.?

Thanks much in advance.

Regards
Aim

推荐答案

（TargetDir）MyProject.exe



to



Editbin.exe / Stack：14000000

(TargetDir)MyProject.exe"

to

Editbin.exe /Stack:14000000 "

（TargetDir）MyProject.exe



有没有人有任何想法可能是什么原因以及我应该去哪些方向。？



非常感谢提前。



问候

目标

(TargetDir)MyProject.exe"

Does anyone have any Idea what could be the cause and what directions should I go in to.?

Thanks much in advance.

Regards
Aim

没有显示异常就不好任何代码示例。但是，通常这个问题很容易解决。



几乎100％的确定这是无限递归或相互递归的结果：

http://en.wikipedia.org/wiki/Recursion [ ^ ]，

http://en.wikipedia.org/wiki/Mutual_recursion [ ^ ]。



使用调试器可以非常系统地解决这些问题。首先，您观察抛出异常的位置。在它发生之前设置一个断点并使用调试器窗口调用堆栈。您将看到来电的来源。找出无限递归的原因并设计退出递归的正确条件。通常，如果将调试与简单的逻辑相结合，可以非常快速地找到错误。



您对至少一个试图被调用的方法进行初步猜测无限次数。通常不需要很长时间才能找到这样的地方。你在这种方法的最开始处设置了断点，并尝试确认它发生了。当在断点上停止执行时，您可以向上或向下堆栈。下去更有效：你保持断点并逐步调试这个方法，首先做大步，直到你捕获相同的方法被深度调用堆栈（记住你的断点仍在那里）。当它发生时，你重新开始并向前走一小步，直到找到递归的位置。这一次试图弄清楚为什么永远不会满足递归结束的条件。同时你将你的断点移近递归呼叫的来源，缩小你的网络。



听起来可能很难，但是很少练习总是给出100％的结果，不同于具有一些未知性质的不同错误的情况。如果堆栈溢出，您可以100％确定在开始查找之前就能找到问题。







注意！



您对 Sleep 告诉我你真的遇到了麻烦，远远超过了例外。而你的修复则更糟，更糟糕的是没有修复。



请阅读： http://en.wikipedia.org/wiki/Race_condition [ ^ ]。



现在的问题非常困难。我基本上告诉你该做什么，在下面的评论中，但真正的分辨率我很简单，但可能需要更多的技巧和时间。



不要忘记这个问题了。







抱歉，我没有提醒您这种可能性。您需要使用一些有根据的猜测来捕获可调试的案例，并稍微修改代码以更改时序。你可能很幸运能够解决问题。



更根本的是，使用 System.Diagnostics.EventLog 。

首先，您需要捕获异常，这很容易。首先，捕获每个线程堆栈的顶部堆栈帧上的所有异常。捕获异常时，记录它，并且重要的是记录所有字符串 System.Exception.StackTrace 。



如果你可以在Debug配置中这样做很好，这很可能。然后堆栈跟踪将为您提供异常传播的确切点。如果没有，您仍然可以使用方法名称找到它。然后，使用此信息获取线索，您可以找到更多针对异常捕获的针脚，仅用于调试目的。



请参阅：

http://msdn.microsoft.com/en-us/library/system.exception .aspx [ ^ ]，

http://msdn.microsoft.com /en-us/library/system.diagnostics.eventlog.aspx [ ^ ]。

-SA

It''s not good to show just the exception without any code sample. However, usually this problem is very easy to solve.

Almost 100% of certainty that this is result of "infinite" recursion or mutual recursion:
http://en.wikipedia.org/wiki/Recursion[^],
http://en.wikipedia.org/wiki/Mutual_recursion[^].

Such problems can be resolved in a very systematic way using the debugger. First, you observe where the exception is thrown. Put a break point before it happens and use the debugger window "Call stack". You will see where the calls come from. Find out the reason for infinite recursion and devise a correct condition of exit from recursion. Usually, the bug can be found very quickly if you combine debugging with simple logic.

You make an initial guess on at least one method which is attempted to get called "infinite" number of times. Usually it does not take long to find such place. You put break point(s) on a very beginning of such method(s) and try to confirm it happens. When the execution is stopped on a breakpoint, you can go up the stack or down the stack. It''s more effective to go down: you keep the breakpoint and debug just one this method stepwise, making big steps at first, until you catch the same method being called deeper in stack (remember your breakpoint is still there). When it happens, you start over and go in smaller step until you pinpoint where the recursion goes. This time try to figure out why the condition of the recursion end is never met. At the same time you move your breakpoint(s) closer to the source of recursive call, narrowing your net.

It may sound difficult, but with little practice always gives 100% results, unlike the cases with different bugs of some unknown nature. In case of stack overflow, you can be 100% sure that you can find the problem before you start looking.



Attention!

Your comment of Sleep tells me that you are in a real trouble, much greater then the exception. And your "fix" is much, much worse then no fix.

Please read: http://en.wikipedia.org/wiki/Race_condition[^].

The problem now is really difficult. I basically told you what to do, in my comment below, but the real resolution my be simple, but may requires a lot more skills and time.

Don''t leave the problem as is.



Sorry, I failed to warn you about this possibility. You need to catch a debuggable case using some educated guess and slightly modifying the code to alter timing. You may be lucky enough to catch the issue.

More radically, research where the problem happens using System.Diagnostics.EventLog.
First of all, you need to catch the exception, which is easy. First of all, catch all exceptions on top stack frame of the stack of each thread. When an exception is caught, log it, and, importantly log all of the string System.Exception.StackTrace.

It''s good if you can do it in Debug configuration, which is likely. Then the stack trace will give you exact points of exception propagation. If not, you still can find it out using just method names. Then, using this information for a clue, you can find more pin-pointed placed for exception catching, just for debug purposes.

Please see:
http://msdn.microsoft.com/en-us/library/system.exception.aspx[^],
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx[^].

—SA

这篇关于堆栈溢出异常，即使在增加堆栈大小后也是如此。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！