程序仅在发布版本时崩溃――如何调试?
我在这里遇到了薛定谔的猫"类型的问题――我的程序(实际上是我的程序的测试套件，但仍然是一个程序)崩溃了，但只有在发布模式下构建时，并且只有在从命令行.通过穴居人调试(即到处都是讨厌的 printf() 消息)，我确定了代码崩溃的测试方法，尽管不幸的是，实际崩溃似乎发生在某些析构函数中，因为我看到的最后一条跟踪消息在其他可以干净执行的析构函数.
I've got a "Schroedinger's Cat" type of problem here -- my program (actually the test suite for my program, but a program nonetheless) is crashing, but only when built in release mode, and only when launched from the command line. Through caveman debugging (ie, nasty printf() messages all over the place), I have determined the test method where the code is crashing, though unfortunately the actual crash seems to happen in some destructor, since the last trace messages I see are in other destructors which execute cleanly.
当我尝试在 Visual Studio 中运行这个程序时，它没有崩溃.从 WinDbg.exe 启动时也是如此.只有从命令行启动时才会发生崩溃.这发生在 Windows Vista 下，顺便说一句，不幸的是我现在无法访问 XP 机器进行测试.
When I attempt to run this program inside of Visual Studio, it doesn't crash. Same goes when launching from WinDbg.exe. The crash only occurs when launching from the command line. This is happening under Windows Vista, btw, and unfortunately I don't have access to an XP machine right now to test on.
如果我能让 Windows 打印出堆栈跟踪，或者除了简单地终止程序，就像它已经干净地退出一样其他东西，那就太好了.有没有人对我如何在此处获取更有意义的信息并希望修复此错误有任何建议?
It would be really nice if I could get Windows to print out a stack trace, or something other than simply terminating the program as if it had exited cleanly. Does anyone have any advice as to how I could get some more meaningful information here and hopefully fix this bug?
问题确实是由越界数组引起的，我在这篇文章中对此进行了更多描述.感谢大家帮助找到这个问题！
The problem was indeed caused by an out-of-bounds array, which I describe more in this post. Thanks everybody for your help in finding this problem!
推荐答案
在我见过或听说过的 100% 的情况下，C 或 C++ 程序在调试器中运行良好，但在外部运行时失败，原因是一直写到函数局部数组的末尾.(调试器会在堆栈上放置更多内容，因此您不太可能覆盖重要的内容.)
In 100% of the cases I've seen or heard of, where a C or C++ program runs fine in the debugger but fails when run outside, the cause has been writing past the end of a function local array. (The debugger puts more on the stack, so you're less likely to overwrite something important.)
相关文章