在从Visual Studio直接执行时,我正在尝试调试一个可执行文件生成可重复输出(我想要的)的问题,但是从命令提示符执行时,它不会产生可重复的输出.这是一个单线程应用程序,所以在时间上不应该有任何奇怪的行为.
有人可以列举两种环境之间可能存在的差异吗？
我确定实际的可执行文件是一样的 – 它们都是发布版本,并且运行的是相同的.exe文件.
以下是环境和结果：
>从命令提示符(cmd)直接运行：不可重复的输出
>从Visual Studio with Debugging(F5)运行：可重复输出
>从Visual Studio运行而不调试(Ctrl-F5)：不可重复输出
我知道工作目录可能会有所不同,但我手动调整,以确保工作目录是一样的.
基于这些结果,它看起来像运行“调试”(即使在发布版本)以某种方式修复了问题.这是否可能是罪魁祸首？运行可执行文件与调试和没有区别？
解决方案：正如在接受的答案中指出的那样,调试堆是问题.问题在于我们的代码很深,有些人在初始化之前访问了大型数组的部分.他们分配了一个malloc的内存,没有将内存初始化为0.调试堆(我假设)用一些可重复的值填充数组,而当调试器没有被附加时(即从命令行运行或与Ctrl-F5)值更随机,有时会导致程序行为微小偏差.不幸的是,调整是微乎其微的,几乎是不明显的,所讨论的记忆在第一个“加工”框架之后被适当重置,但初始条件已经略有不同,损坏已经完成.混沌理论在行动！感谢您的指导.
一个很好的调试提示,帮助您：编写一个自定义的malloc,立即用完全随机的数据填充内存.这样,您可以确保在使用之前自己正确初始化它,否则您的结果将(希望)每次运行时都会变得疯狂 – 即使在调试模式下也可以使用调试堆！
解决方法
Windows Heap behaves differently if process is started under the debugger.要禁用此行为(为了在调试时发现问题)将_NO_DEBUG_HEAP = 1添加到环境(如
this question).
或者,您可以附加到程序执行的早期处理.堆将不会进入调试模式.将DebugBreak()行添加到执行开始的某个位置,使用Ctrl F5运行,并在被要求时开始调试.
