从VS2005移动到VS2008（win32）后，我的应用程序崩溃（重复）。
如果我进入调试器，我会得到：
Access violation reading location 0x00000014
首先，我看到崩溃线上的类对象有一个NULL _vptr。但是同一类的其他一些对象具有非NULL _vprt：）
其次，如果我改变成员对象声明的顺序，则崩溃会移动到其他行。
所以我想这肯定是一个腐败的堆问题。
你同意吗？如果是，堆栈中的分配数量如“char buffer [8192]”可能会成为问题吗？我试过purify，应用程序验证程序没有运气。我的应用程序是一个生活在专有应用程序中的插件（dll）。我只能附加一个调试器。
提前致谢，
保
答案 0 :(得分：3)
你同意吗？如果是，那么堆栈中的分配数量（例如char buffer[8192]）是否会成为问题？
是的，Heap损坏可能是由Heap上分配的一大堆大小引起的（通过使用new或malloc）。如果要在Stack上创建一个巨大的数组，如果相邻的内存被分配给另一个对象，程序将覆盖该对象的数据，从而导致崩溃。所以两者都可能有危险，但由于不同的问题。如果你在谈论堆栈数组，不能它不会导致堆损坏只是因为堆栈或堆（而不是C ++中的免费存储）是两个不同的内存实体。
堆腐败可能非常令人沮丧且难以诊断。虽然有许多方法可以尝试调试这些错误，但是没有明确的步骤可以解决这样的问题。
Debugging Heap Corruption in Visual C++ Using Microsoft Debugging Tools for Windows 是一个很好的来源，它记录了visual c ++特有的技术
答案 1 :(得分：1)
这肯定看起来像堆损坏 - 在某些时候，你的代码在对象的顶部写入零，并且杀死了vptr。从VS2005迁移到VS2008后发生的原因可能是因为堆布局有些变化。这个错误也可能出现在VS2005中，但它的损坏却没有被注意到。
使用您提到的工具通常可以解决此类问题。使用它们时你有什么运气？
由于您说您的应用重复以相同的方式崩溃，您可以在代码中添加检查。连续验证受损物体（确保其开始未归零），并在观察到损坏时断裂。查看最新成功验证和休息之间的活动将有助于您集中精力。请记住，堆使用中的任何更改都可能会隐藏问题，即损坏其他位置。
答案 2 :(得分：1)
事实证明这是一个与预处理器相关的问题，定义了我的应用程序和它的一些依赖项（libs）之间的不同。