delphi - FastMM4、DebugGetMem 中偶尔出现访问冲突

Question

我正在尝试追踪访问冲突。可重复性似乎是不确定的，而且很少见，所以我想在进一步讨论之前检查一下我的一些假设。

FastMM4 版本 4.991 的函数 DebugGetMem 中引发了访问冲突。 ，在以下代码中:

if (ASize > (MaximumMediumBlockSize - BlockHeaderSize - FullDebugBlockOverhead))
    or CheckFreeBlockUnmodified(Result, GetAvailableSpaceInBlock(Result) + BlockHeaderSize, boGetMem) then
  begin
    {Set the allocation call stack}
    GetStackTrace(@PFullDebugBlockHeader(Result).AllocationStackTrace, StackTraceDepth, 1);
    {Set the thread ID of the thread that allocated the block}
    PFullDebugBlockHeader(Result).AllocatedByThread := GetThreadID; // ** AV Here
    {Block is now in use: It was allocated by this routine}
    PFullDebugBlockHeader(Result).AllocatedByRoutine := @DebugGetMem;

异常(exception)情况是:

Project Workstation.exe raised exception class $C0000005 with message 'access violation at 0x01629099: read of address 0x66aed8f8'.

调用堆栈通常是相同的。它是从虚拟 TreeView 上的绘画事件中调用的，我在其中调用 Format('%s %s %s', [vid, node, GetName()])尽管我怀疑这是否真的相关(除了 Format 分配动态内存之外)。

我正在使用FullDebugMode (显然)和CheckHeapForCorruption选项。

我还建立了以下内容:

1. 正在开启CatchUseOfFreedInterfaces没有显示任何新内容。我仍然遇到相同的访问冲突，并且没有进行额外的诊断。
2. 我曾经用FullDebugModeScanMemoryPoolBeforeEveryOperation := True重现了崩溃，虽然我不记得是否 CatchUseOfFreedInterfaces这次是打开还是关闭。
3. 这不是线程并发问题；我的应用程序是单线程的。 (实际上，这并不完全正确。我正在使用 Virtual TreeView，它创建了一个隐藏的工作线程，但如果这确实是原因，那么错误就在 Virtual TreeView 中，而不是我的代码中，这是不太可能的。)

我的想法对吗，尽管 CheckHeapForCorruption没有捕捉到任何东西，这个异常只能是由于我的代码破坏了堆？还有其他什么可能导致 FastMM4 以这种方式崩溃吗？

对于进一步诊断，甚至使崩溃更具重现性，有什么建议吗？

Answer 1

虽然看起来很奇怪，但这是正常行为。如果切换到 CPU View ，您将看到指令指针位于 FastMM_FullDebugMode.dll 模块内。 FastMM 的某些调试功能在设计上可能会引发访问冲突。如果继续执行你会发现你的应用程序运行正确。

调试 session 以这种方式中断可能会非常令人沮丧。我had some discussion with the FastMM author关于一个相关问题。看起来 FastMM 调试 DLL 确实被设计为以这种方式工作，结论是没有太多方法可以阻止这些外部异常的引发。

如果有人认识到这种挫败感，并有一个好的解决方案，我将永远感激不已。