FastMM4，DebugGetMem中偶爾的訪問沖突

Question

我正在嘗試追蹤訪問沖突。 再現性似乎是非確定性的，並且很少見，因此我想在進一步研究之前檢查一些我的假設。

在函數DebugGetMem中的FastMM4版本4.991中引發了訪問沖突，代碼如下：

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，消息“訪問沖突位於0x01629099：讀取地址0x66aed8f8”。

調用堆棧通常是相同的。 它是從虛擬樹視圖上的繪制事件中調用的，我稱之為Format('%s %s %s', [vid, node, GetName()])雖然我懷疑它是否真的相關（除了格式分配動態）記憶）。

我正在使用FullDebugMode （顯然）和CheckHeapForCorruption選項。

我還建立了以下內容：

1. 啟用CatchUseOfFreedInterfaces不會顯示任何新內容。 我仍然得到相同的訪問沖突，沒有其他診斷。
2. 我曾經使用FullDebugModeScanMemoryPoolBeforeEveryOperation := True重現了崩潰，雖然我不記得CatchUseOfFreedInterfaces是否在此時開啟或關閉。
3. 它不是線程並發問題; 我的應用程序是單線程的。 （實際上，這不是真的。我正在使用Virtual TreeView，它創建了一個隱藏的工作線程，但如果真的是這個原因那么bug就在Virtual TreeView中，而不是我的代碼，這是不太可能的。）

我是否正確地認為，盡管CheckHeapForCorruption沒有捕獲任何東西，但這個異常只能是因為我的代碼破壞了堆？ 還有什么可能導致FastMM4以這種方式崩潰嗎？

有關進一步診斷的建議，甚至使崩潰更可重復嗎？

Answer 1

盡管看起來很奇怪，但這是正常行為。 如果切換到CPU視圖，您將看到指令指針位於FastMM_FullDebugMode.dll模塊內。 根據設計，FastMM的某些調試功能可能會引發訪問沖突。 如果繼續執行，您將發現應用程序正確運行。

以這種方式中斷調試會話可能會非常令人沮喪。 我在相關問題上與FastMM作者進行了一些討論 。 似乎FastMM調試DLL設計為以這種方式工作，結論是沒有太多可以做的來阻止引發這些外部異常。

如果那里的任何人都認識到這種挫敗感，並且有一個很好的解決方案，我會永遠感激。