delphi - 当前 FastMM 版本与 Delphi XE 默认版本

Question

我们在 Delphi XE 中处理第 3 方组件线程代码的方式上遇到了问题。我说第 3 方是因为我们的核心应用程序本身没有实现任何多线程代码。我确定的是，如果我使用 SimpleShareMem(我们有几个与主应用程序共享字符串数据的 dll)，就会发生奇怪的内存损坏，但如果我安装 FastMM4 单元，这些错误就会消失。我所说的奇怪是指错误很少连续两次相同，尽管它们位于相同的总体区域。我最初安装 FastMM4 是为了尝试确定错误原因，但实际上安装时根本没有发生这些错误。我在选项集中设置了条件，允许我在 SimpleShareMem 和 FastMM 之间来回翻转项目组中的所有模块，并且可以很容易地证明我的结论。

我的直接例子是 TRichView。我发现，当我使用 hunspell 拼写检查器时，通过同时粘贴和向上单击滚动相当多次，我可以在 PaintBuffered/PaintTo 过程中或附近产生错误(这取决于我需要多少次)这样做会产生错误)。有时它是一个外部异常，解析为一个表面异常，其他时候我在异常处理代码中遇到堆栈溢出。

我遇到的另一个例子是 AnyDAC (DA-SOFT) 远程/文件监控系统，也在单独的线程中运行，它无法与 SimpleShareMem 一起使用，但与 FastMM4 一起工作正常。

基于这些经验，我被迫使用 FastMM4 单元进行生产构建，尽管这对我来说也很奇怪。当然，我总是首先怀疑我自己的代码，所以我想知道我是否可以做一些事情来加剧问题，尽管 FastMM4 没有显示主应用程序有任何堆栈损坏等。

所以，我的问题是，有人能想到为什么 FastMM4 比 Delphi XE 使用的 FastMM 版本更适合多线程操作吗？

更新:我想补充一点，我现在已经使用旧的 Sharemem/borlndmm.dll 概念进行了一些测试，并且效果也很好。

更新2:感谢您的建议。我一直试图找到导致我的问题的 heisenbug，但收效甚微。我确实有一个额外的观察。

如果我修改主应用程序，使其不加载需要 ShareMem 的 DLL，则无论我使用什么内存管理器，AnyDAC 日志记录或 TRichView 都不会出现问题。即使我没有调用该 DLL，加载该 DLL(启动 FastMM 的初始实例并与主应用程序共享)的行为也会导致问题。我要做的下一件事是修改主应用程序以启用该 dll 的动态加载(从而强制将内存管理器安装到主应用程序中)，看看这是否会产生影响。

更新 3:动态加载 dll 与不加载它具有相同的效果...一切正常。

Answer 1

Delphi XE 中嵌入的内存管理器是 FastMM4 的精简版本。

内存块分配器本身是相同的，但共享机制不一样。

默认情况下，在 FastMM4Options.inc 中设置以下条件:

{Define this to enable backward compatibility for the memory manager sharing
 mechanism used by Delphi 2006 and 2007, as well as older FastMM versions.}
{$define EnableBackwardCompatibleMMSharing}

它将为库创建一个隐藏的窗口句柄来检索共享内存管理器实例 - 这就是它与 Delphi 2006 和 2007 一起工作的方式。

自 Delphi 2009 以来，在 GetMem.inc 中实现的 FastMM4 精简版本中不再存在这种共享 - 它仅实现共享内存管理器文件映射(这是新方法)。其中一个库可能需要旧版本的内存管理器共享，无法找到共享内存管理器实例，因此使用自己的内存分配器 - 并且无法处理共享内存(例如string实例)。

这是我发现两个版本之间的唯一区别，这可能是共享在您的程序中无法按预期工作的原因。您可能有一些使用 Delphi 2006 或 2007 编译的库，并且 Embarcadero 不推荐使用共享方法(为了节省一些代码字节？)。