如何缩小堆栈溢出异常? [英] How to narrow down a stack overflow exception?

问题描述

我有最后期限.我正在谷歌搜索，正在阅读代码，需要帮助...

I have a deadline. I am googling, I am code reading, I neeed help ...

我的应用程序抛出EStackOverFlow.需要通宵测试才能发现错误，因此我需要一些好主意，否则将需要很长时间( )进行跟踪.

My Application is throwing an EStackOverFlow. It requires an overnight test to hit the error, so I need some good ideas or it will take a long time to track down.

我昨晚尝试使用MAD Except，但是没有抓住它，大概是因为没有栈可以这样做.我在IDE上运行，因此中断了执行并查看了Call Stack，但除细节外，MAD充满了MAD(我已经联系了作者，但我们之间有很大的时差).

I tried last night with MAD Except, but that didn't catch it, presumably because there was no stack for it to do so. I was running from the IDE so I broke execution and looked at the Call Stack, but it was filled with MAD except details (I have contacted the author, but there is a big time difference between us).

没有(故意)递归的递归例程.没有OnChange处理程序(这可能会意外更改其监视的组件，从而以递归方式对其进行调用).没有大的数据结构(可以作为参数传递到堆栈上).

There are no (deliberately) recursive recursive routines. No OnChange handlers (which might accidentaly change the component which they monitor, thus calling themselves recursively). No large data structures (which might be passed on the stack as parameters).

我的第一个想法是关闭MAD Except，但是我迫不及待要等待12到16个小时才能崩溃.

My first thought is to turn off MAD Except, but I can't wait another 12 or 16 hours for a crash.

无人值守，当计时器每30秒或每小时到期时，程序正在进行一些数据库访问，因此我将其设置为1秒，希望能加快崩溃速度.嗯，我可以减小堆栈大小以加快崩溃速度吗?如果可以，怎么办?

Unattended, the program is doing some database access when timers expire every 30 seconds or every hour, so I have set those to 1 second, hoping to hasten the crash. Hmm, can I reduce the stack size in order to hasten the crash? If so, how?

我还能做什么?我在尝试...除外"中包装了我的应用程序主文件，该文件用于创建表单并运行该应用程序.

What else can I do? I have wrapped my applications main file, where forms are created and the application is run, in Try ... Except.

是否存在某些点(例如消息处理循环)，在该点上我可以检查堆栈大小并查看堆栈是否正在太大"?(如果是这样，您能提供详细信息吗?)

Is there some point, such as the message handling loop, where I can check the stack size and see if it is growing "too large"? (if so, can you give details?)

还有其他建议吗?预先感谢

Any other suggestion? Thanks in advance

(请注意，代码太大而无法发布)

(p.s the code is far too large to post)

推荐答案

AS.我上面提到的探查器方法可能会给您带来纯粹的运气(如果有一些杂散的分支会导致您罕见但即时的泄漏.请说，在100个案例变体中，唯一的一个会导致无限递归).但是，如果存在稳定的累积泄漏，需要整夜进行累积，则探查器结果将无法与正常工作区分开.

AS. Profiler approach i noted above might give you result by sheer luck (if there is some stray branch leading you to rare but instant-fast leak. Say, among 100 case variants there is the only one leading to infinite recursion). However if there is steady cumulative leak, that takes all night to accumulate itself, then profiler results would not be distinguishable from normal work.

我想了一下.当前的假设是，由于没有剩余的堆栈，堆栈跟踪器将失败.让我们握住它.然后我们将在堆栈结束之前抛出异常，是吗?所以我会尝试以下顺序:

I thought a bit. Current hypothesis is that stack tracers fail for there is no stack left. Let's hold it. Then we shall throw exception before stack is over, yes ? So i'd try this sequence:

1)我将堆栈跟踪器设置为记录包括行号在内的完整堆栈跟踪.可以在Delphi IDE使用的JCL跟踪器中完成此操作，我认为madExcept也可以.

1) i'd set stack tracer to log full stack trace including line numbers. It can be done in JCL tracers used by Delphi IDE, and i think madExcept can too.

2)我想知道当前的堆栈大小.例如使用Visual Studio确定堆栈空间

2) i'd like to know the current stack size. For example Determining Stack Space with Visual Studio

3)我会定期检查已使用的堆栈空间.例如什么是一个安全的最大堆栈大小或如何衡量堆栈使用情况?

3) i'd keep regularly checking used stack space. For example What is a safe Maximum Stack Size or How to measure use of stack?

注意:由于我们几乎不知道是哪个线程导致了这种情况-如果我的线程很少，我将尝试使用所有这些线程.我只是不知道如果某个辅助线程因SO失败而导致应用程序会如何反应，会被截取并记录日志，或者整个应用程序只会被一个线程炸毁

4)〜每隔5分钟，我会记录当前的堆栈使用情况-只是为了查看模式，如果它稳步缓慢发展，或者它是罕见但严重的代码路径.如果有多个线程-那么每个线程有多个日志文件它还可以估计正常"的堆栈使用情况.

4) ~ every 5 minutes i'd log current stack usage - just to see the pattern, if it is steadily slowly goring, or is it some rare but severe codepath. If several thread - then several log files one per thread It would also allow to estimate the "normal" stack usage.

5)如果堆栈使用率提高到80％以上(我认为您的正常"使用率todl不会超过它，不是吗?)我会提出手动异常，某些特殊类直到线程被捕获/app顶层，甚至在顶层可能还会做一些复杂的事情，例如将应用程序暂停到调试器中并唤醒您，以便您可以远程连接并检查有病但尚未死亡的应用程序的内部状态.

5) if stack usage raises above 80% (i think your "normal" usage todl above would not exceed it, won't it?) i'd raise manual exception, some special class that would not be caught until thread/application top level, and at top level maybe even do something complex, like halting the app into debugger and awaking you so you can remotely connect and check the internal status of sick yet not deceased yet app.

这篇关于如何缩小堆栈溢出异常?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！