blocks|key|4617814|text|我不排除在Windows中有这样的处理程序，但我从来没有听说过。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4617815|我觉得你展示的回溯可能是假的。如果您在某种类型的损坏已经发生之后进入该进程，则回溯不一定有效。但是，如果幸运的话，堆栈跟踪的底部仍然有一些关于正在发生的事情的线索。|4617816|尝试将Sleep()调用放入源代码中可能涉及到递归的选定函数中。这应该会让你有更好的机会在堆栈完全溢出之前进入进程。|offset|length|style|CODE|4617817|entityMap^0|0|0|3|7|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I wouldn't rule out there being such a handler in Windows, but I've never heard of it.

I think the traceback that you're showing may be bogus. If you broke into the process after some kind of corruption had already occurred, then the traceback isn't necessarily valid. However, if you're lucky the bottom of the stack trace still has some clues about what's going on.

Try putting <code>Sleep()</code> calls into selected functions in your source that might be involved in the recursion. That should give you a better chance of breaking into the process before the stack has completely overflowed.

blocks|key|1142525|text|乍一看，这确实像是无限递归，您可以尝试在终止进程的行前放置一个断点。它能到那里吗？如果是这样的话，您有两种相当容易的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1142526|要么你只是向前一步，看看调用了哪些析构函数，什么时候它被捕获了。或者你可以在每个相关的对象析构函数中放一个printf/OutputDebugString+(全局的ONly应该需要这个)。如果消息是析构函数做的第一件事，那么你看到的最后一条消息是来自析构函数，它会挂起东西。|1142527|另一方面，如果它没有到达我最初提到的那个断点，那么可以做一些类似的事情，但它会更烦人，因为程序仍然在“做事情”。|1142528|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

That does look at first glance like an infinite recursion, you could try putting a breakpoint at the line before the one that terminates the process. Does it get there ok? If it does, you've got two fairly easy ways to go.

Either you just step forward and see which destructors get called and when it gets caught up. Or you could put a printf/OutputDebugString in every relevant objects destructor (ONly ones which are globals should need this). If the message is the first thing the destructor does, then the last message you see is from the destructor which hangs things up.

On the other hand, if it doesn't get to that breakpoint I originally mentioned, then can do something similar, but it will be more annoying since the program is still "doing stuff".

blocks|key|1142562|text|若要控制Windows在发生访问冲突时执行的操作+(SIGSEGV-equivalent)，请调用SetErrorMode+(向其传递参数0以在出现错误时强制弹出窗口，从而允许您使用调试器附加到该弹出窗口)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|1142563|但是，根据您已经获得的堆栈跟踪，在调试器出现故障的情况下附加可能不会产生任何额外的信息。您的堆栈已损坏，或者递归深度已超过VS可显示的最大帧数。在后一种情况下，您可能想要减少process的默认堆栈大小(使用项目属性中的/F开关或等效选项)，以使问题更早地显现出来，并确保VS将显示所有帧。或者，您可能希望在std::basic_filebuf<>::flush()中放置一个断点，并遍历它直到销毁阶段(或者禁用它直到销毁阶段之前)。|1142564|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms680621(VS.85).aspx^0|0|O|Q|7|1D|C|1D|C|0|0|U|D|32|2|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|D]|$9|V|A|W|B|D]]|E|@$9|X|A|Y|1|Z]]|F|$]]|$1|G|3|H|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|D]]|E|@]|F|$]]|$1|I|3|-4|5|6|7|15|8|@]|E|@]|F|$]]]|J|$K|$5|L|M|N|F|$O|P]]]]

To control what Windows does in case of an access violation (<code>SIGSEGV</code>-equivalent), call <a href="http://msdn.microsoft.com/en-us/library/ms680621(VS.85).aspx" rel="nofollow noreferrer"><code>SetErrorMode</code></a> (pass it parameter 0 to force a popup in case of errors, allowing you to attach to it with a debugger.)

However, based on the stack trace you have already obtained, attaching with a debugger on fault may yield no additional information. Either your stack has been corrupted, or the depth of recursion has exceeded the maximum number of frames displayable by VS. In the latter case, you may want to decrease the default stack size of the process (use the <code>/F</code> switch or equivalent option in the Project properties) in order to make the problem manifest itself sooner, and make sure that VS will display all frames. You may, alternatively, want to stick a breakpoint in std::basic_filebuf&lt;>::flush() and walk through it until the destruction phase (or disable it until just prior to the destruction phase.)

blocks|key|1142598|text|好吧，你知道问题在哪条主线上--这可能是一个简单的问题，从一开始就追踪它，看看它在哪里深入到杂草中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1142599|另一种选择是使用Debugging+Tools+for+Windows包中的调试器之一-它们可能比VS调试器显示更多(可能)，即使它们通常更复杂和难以使用(实际上可能正因为如此)。|offset|length|1142600|entityMap|0|LINK|mutability|MUTABLE|url|http://www.microsoft.com/whdc/devtools/debugging/default.mspx^0|0|8|R|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Well, you know what thread the problem is on - it might be a simple matter of tracing through it from inception to see where it goes off into the weeds.

Another option is to use one of the debuggers in the <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx" rel="nofollow noreferrer">Debugging Tools for Windows</a> package - they may be able to show more than the VS debugger (maybe), even if they are generally more complex and difficult to use (actually maybe because of that).

blocks|key|3773017|text|我同意丹·布雷斯劳的观点。你的堆栈是假的。可能很简单，因为你没有正确的符号。如果一个程序在没有WER处理的情况下就消失了，那通常是内存不足。你有没有调查过这种可能性？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3773018|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 agree with Dan Breslau. Your stack is bogus. may be simply because you don't have the right symbols, though.
If a program simply disappears without the WER handling kicking in, it's usually an out of memory condition. Have you gone investigated that possibility ?

So I'm trying to debug this strange problem where a process ends without calling some destructors...

In the VS (2005) debugger, I hit 'Break all' and look around in the call stacks of the threads of the misteriously disappearing process, when I see this:

<a href="http://img6.imageshack.us/img6/7628/95434880.jpg" rel="nofollow noreferrer">smells like SO http://img6.imageshack.us/img6/7628/95434880.jpg</a>

This definitely looks like a SO in the making, which would explain why the process runs to its happy place without packing its suitcase first.

The problem is, the VS debugger's call stack only shows what you can see in the image.

So my question is: how can I find where the infinite recursion call starts?

I read <a href="https://stackoverflow.com/questions/81202/segfault-on-stack-overflow" title="somewhere">somewhere</a> that in Linux you can attach a callback to the SIGSEGV handler and get more info on what's going on.

Is there anything similar on Windows?

debug stack overflow in windows?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

所以我正在尝试调试这个奇怪的问题，在这个问题中，进程在没有调用析构函数的情况下结束...在VS (2005)调试器中，我点击了'Break all‘，并查看了misteriously进程的线程的调用堆栈，当我看到以下内容时：这看起来肯定像是一个正在形成的SO，这将解释为什么这个过程在没有事先打包行李箱的情况下就会运行到...

问windows中的调试堆栈溢出？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问windows中的调试堆栈溢出？EN