FastMM4，DebugGetMem中的偶然訪問衝突

我試圖追查訪問衝突。再現性似乎不確定，而且很少見，所以我想在進一步研究之前檢查一些我的假設。FastMM4，DebugGetMem中的偶然訪問衝突

訪問衝突引發的FaseMM4，版本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 raised exception class $C0000005 with message 'access violation at 0x01629099: read of address 0x66aed8f8'.

調用堆棧通常是相同。它被虛擬樹視圖中的paint事件調用，其中我稱之爲Format('%s %s %s', [vid, node, GetName()])，儘管我懷疑它確實是相關的（除了Format分配動態內存之外）。

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

我也設立了以下：

打開CatchUseOfFreedInterfaces不顯示任何新的東西。我仍然得到相同的訪問衝突，並且沒有額外的診斷。
我曾經用FullDebugModeScanMemoryPoolBeforeEveryOperation := True重現了這次事故，但我不記得CatchUseOfFreedInterfaces是否在這個時候開啓或關閉。
這不是線程併發問題;我的應用程序是單線程的。（實際上，這並不是真的，我使用虛擬TreeView，它創建了一個隱藏的工作線程，但如果真的是這個原因，那麼這個錯誤是在虛擬TreeView中，而不是我的代碼，這是不太可能的。）

我是否認爲，儘管CheckHeapForCorruption沒有捕捉任何東西，這個異常只能是由於我的代碼破壞堆？還有什麼可能導致FastMM4以這種方式崩潰？

任何有關進一步診斷的建議，或甚至使得崩潰更具可重現性？

來源

2014-03-27 Ian Goldby

雖然看起來很奇怪，但這是正常的行爲。如果切換到CPU視圖，您將看到指令指針位於FastMM_FullDebugMode.dll模塊內。 FastMM的一些調試功能可以通過設計提高訪問違規。如果你繼續執行，你會發現你的應用程序運行正常。

調試會話以這種方式中斷會非常令人沮喪。我在had some discussion with the FastMM author上有相關的問題。看起來FastMM調試DLL被設計爲以這種方式工作，結論是沒有太多的事情可以做到阻止這些外部異常被引發。

如果有人認識到這種沮喪，並且有一個很好的解決方案，我將永遠感激。

來源

2014-03-27 11:07:49

我想知道我曾經試過在這種例外後繼續執行。現在我必須等待錯誤再次發生，然後才能嘗試。如果這有效（即適用於我的情況），那麼我將永遠感激！我會盡快發佈更新。（可能是幾天，甚至幾周。） –

是的。我剛剛得到一個，繼續執行，顯然一切都很好。哦，只有兩天浪費在這個'問題'上。謝謝，大衛。 –

總結一下：忽略AV？ – Ampere

FastMM4，DebugGetMem中的偶然訪問衝突

回答

相關問題