delphi - 将 COM-DLL 从 Delphi 2007 移植到 Delphi 2009 后，如何诊断 COM-DLL 中发生的内存损坏错误？

Question

我刚刚将几个自制的 Outlook COM 插件从 Delphi 2007 移植到 Delphi 2009，现在遇到了一些非常奇怪的错误(在你问之前:这些错误似乎与字符串处理没有任何明显的关系) ，例如，模式对话框在尝试第二次调用它们时挂起 Outlook(第一次一切似乎都很好)，但仅当它们是从一个特定事件处理程序调用时而不是在其他地方执行相同操作时挂起。当我将错误跟踪到特定的代码行并注释掉该行或将其替换为不同的代码以达到相同的效果(例如，通过将原本通过函数直接调用的代码复制到调用站点)时，将出现错误离开 - 通常只会在稍后重新出现几个(同样不显眼的)语句。

当在 Delphi 调试器中运行此命令时，我可以看到卡住之前通常会发生 GetMem.inc 中的访问冲突。至少所有这些问题都是 100% 可重现的......

不用说，在 Delphi 2007 中编译这些插件时，我们没有遇到这些问题。

现在，我很茫然。我知道我很幸运，但尽管我认为自己是一个相当有经验的程序员(尽管主要是在利基领域)，但我以前从未真正处理过此类错误。正如这个问题的标题所说，我什至不知道从哪里开始。我可以随心所欲地单步调试代码，但无休止的汇编语句对我来说毫无意义，而且我也不擅长有效地使用 CPU View 。

此外，我什至还不确定这是否是我自己的代码的问题(在这种情况下我实际上倾向于怀疑)。我们正在大量使用许多第三方库(例如 JCL、ADX、Redemption)。特别是 ADX 仍将其 Delphi 2009 支持标记为“测试版”。

我还尝试使用 FastMM 的 FullDebugMode，实际上我确实通过这种方式发现了 ADX 中的许多错误(例如，释放后修改的 block )，但所有这些也会在我使用 Delphi 2007 编译时发生，所以它不会但似乎势在必行的是，这些最终是观察到的回归的原因。

那么，我该如何处理这个问题呢？ - 或者更好的是:我在哪里可以找到一些学习如何处理这个问题的好资源？例如有关使用 CPU View 或有效解释 FastMM 发布的报告并采取行动的教程？这些是正确的工具吗？我还应该看哪里？

附录:
在这种情况下我应该怀疑哪些类型的代码？什么样的代码有可能对内存造成如此严重的破坏？我能想到的代码执行任何远程显式内存操作的唯一地方是在准备 WinAPI 调用时保留一些缓冲区空间。另请记住，我的所有代码在 Delphi 2007 和 Delphi 2009 版本之间都是相同的，并且 Delphi 2007 版本没有出现此类问题。

更新:
有可能促使我提出这个问题的问题现在已经解决了。请参阅下面我自己的回答。

Answer 1

获得解决方案的最佳工具可能是内存断点。

调试内存损坏是痛苦的，所以首先尝试让你的生活尽可能简单:找到一组每次都有效的、精确的、保证可重复的步骤。如有必要，请模拟 Outlook 主机，以便您无需依赖 Outlook 计时问题或解决空间布局问题等。

您必须获得一组可靠、可重现的步骤，这些步骤会在可预测地址处导致反病毒或其他错误。

然后您要做的就是重新启动进程，为引用该地址的任何内容创建一个内存断点集，并熟悉该内存块的生命周期。最小化和合理化您的复制步骤在这里会有所帮助。添加其他断点并仅稍后在应用程序中启用内存断点可能会有所帮助；或者使用 D2009 断点的日志记录功能来记录内存值/调用堆栈等，而不是实际闯入调试对象。<​​/p>