我们在Delphi XE中处理第三方组件线程代码的方式出现了问题。我说第三方是因为我们的核心应用程序没有自己实现任何多线程代码。我已经确定,如果我使用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的动态加载(从而强制内存管理器安装到主应用程序中),看看是否有所不同。
我的即时示例是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与不加载它具有相同的效果...一切正常运作。