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;

异常情况是：

Project Workstation.exe引发异常类$C0000005，消息为“访问地址0x66aed8f8时读取地址0x01629099”。

调用堆栈通常相同。它是从虚拟树视图的绘制事件中被调用的，在其中我调用了Format('%s %s %s', [vid, node, GetName()])，尽管我怀疑这并不重要（除了Format分配动态内存之外）。

我正在使用FullDebugMode（显然）和CheckHeapForCorruption选项。

我还确定了以下内容：

1. 启用CatchUseOfFreedInterfaces没有显示任何新信息。我仍然得到相同的访问冲突，没有额外的诊断信息。
2. 我曾经使用FullDebugModeScanMemoryPoolBeforeEveryOperation := True复制了崩溃，尽管我无法记得此时是否开启了CatchUseOfFreedInterfaces。
3. 这不是线程并发问题；我的应用程序是单线程的。（实际上，这并不完全正确。我正在使用虚拟树形视图，它创建了一个隐藏的工作线程，但如果这真的是原因，那么错误就在虚拟树形视图中，而不是我的代码，这是相当不可能的。）

我是否正确地认为，尽管CheckHeapForCorruption没有捕获到任何东西，此异常只能是由于我的代码损坏了堆栈？还有其他导致FastMM4以这种方式崩溃的原因吗？

有关进一步诊断的建议，甚至使崩溃更易于复制的建议吗？

- Ian Goldby

Answer 1

奇怪的是，这是正常行为。如果您切换到CPU视图，您将看到指令指针位于FastMM_FullDebugMode.dll模块内部。FastMM的一些调试功能可以通过设计引发访问冲突。如果继续执行，您会发现应用程序运行正确。

调试会话以这种方式中断可能会非常令人沮丧。我曾就相关问题与FastMM的作者进行过讨论。似乎FastMM调试DLL是按照这种方式设计的，结论是无法阻止引发这些外部异常的操作很少。

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

- David Heffernan

---

我在想我是否曾经尝试过在这样的异常情况下继续执行程序。现在我必须等待错误再次发生，然后再尝试。如果这行得通（即适用于我的情况），那么我将永远感激不尽！我会在第一时间发布更新。（可能需要几天，甚至几周。） - Ian Goldby

好的。我刚刚拿到了一个，继续执行，一切显然都很好。哦，只是浪费了两天时间在这个“问题”上。谢谢，David。 - Ian Goldby

@SolarWind 是的，过一段时间后你会习惯并认识它。 - David Heffernan

@SolarWind 是的，直到你意识到你的代码没有问题，这是非常令人沮丧的！ - David Heffernan

所以，测试方法是：在调试器中看到 AV 后，按 F9 继续执行程序。如果没有崩溃，那么我们就知道我们遇到了“107209”错误。 - Gabriel