FastMM4，DebugGetMem中偶尔访问冲突 [英] Occasional access violation in FastMM4, DebugGetMem
问题描述
我正在尝试追踪访问冲突。重现性似乎是非确定性的，很少见，所以我想在我进一步了解之前先检查一下我的假设。
I'm trying to track down an access violation. Reproducibility seems non-deterministic, and rare, so I want to check a few of my assumptions before I go any further.
访问冲突在FaseMM4 4.991 ，在函数DebugGetMem中，在以下代码中：
The access violation is raised in FaseMM4, version 4.991, in the function DebugGetMem, in the following code:
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事件中调用，其中我调用了格式（'％s％s％s'，[vid，node，GetName（）]）我怀疑这是真的相关（除了格式分配动态内存）。
The call stack is usually the same. It's being called from a paint event on the virtual treeview in which I call Format('%s %s %s', [vid, node, GetName()]) though I doubt that is really relevant (other than that Format allocates dynamic memory).
我正在使用 FullDebugMode 显然）和 CheckHeapForCorruption 选项。
I'm using FullDebugMode (obviously) and CheckHeapForCorruption options.
我还建立了以下内容：
- 打开
CatchUseOfFreedInterfaces不显示任何新内容。我仍然得到相同的访问冲突，没有额外的诊断。 - 我曾经以
FullDebugModeScanMemoryPoolBeforeEveryOperation：= True不记得在这个场合是否开启或关闭CatchUseOfFreedInterfaces - 这不是一个线程并发问题;我的应用程序是单线程的。 （实际上，这并不完全正确，我使用的是Virtual TreeView，它创建一个隐藏的工作线程，但是如果真的是这个原因，那么这个bug就在Virtual TreeView中，而不是我的代码，这不太可能。） / li>
- Turning on
CatchUseOfFreedInterfacesdoesn't show anything new. I still get the same access violation, and no additional diagnostics. - I once reproduced the crash with
FullDebugModeScanMemoryPoolBeforeEveryOperation := True, although I can't remember whetherCatchUseOfFreedInterfaceswas on or off on this occasion. - It isn't a thread concurrency issue; my application is single-threaded. (Actually, this isn't quite true. I'm using Virtual TreeView, which creates a hidden worker thread, but if this really is the cause then the bug is in Virtual TreeView, not my code, which is rather unlikely.)
我正好在想，尽管 CheckHeapForCorruption 没有捕捉任何东西，这个异常只能由于我的代码破坏了堆？有没有什么可以导致FastMM4以这种方式崩溃？
Am I right in thinking that, despite CheckHeapForCorruption not catching anything, this exception can only be due to my code corrupting the heap? Is there anything else that could cause FastMM4 to crash in this way?
任何进一步诊断的建议，甚至使崩溃更可重现？
Any suggestions for further diagnostics, or even making the crash more reproducible?
推荐答案
虽然看起来很奇怪，这是正常的行为。如果切换到CPU视图，您将看到指令指针位于FastMM_FullDebugMode.dll模块内。 FastMM的一些调试功能可以通过设计来提高访问冲突。如果继续执行，您会发现应用程序正常运行。
Strange though it may seem, this is normal behaviour. If you switch to the CPU view you will see that the instruction pointer is located inside the FastMM_FullDebugMode.dll module. Some of the debugging functionality of FastMM can, by design, raise access violations. If you continue execution you will find that your application runs correctly.
调试会话以这种方式中断，这可能非常令人沮丧。有关相关问题，我与FastMM作者进行了一些讨论。似乎FastMM调试DLL被设计为以这种方式工作，结论是没有什么可以做的，以阻止这些外部异常引发。
It can be quite frustrating that debugging sessions are interrupted in this way. I had some discussion with the FastMM author on a related issue. It does seem that the FastMM debug DLL is designed to work this way the conclusion is that there's not a lot that can be done to stop these external exceptions being raised.
如果任何人都认识到这种沮丧，并有一个很好的解决方案，我将永远感激。
If anyone out there recognises this frustration, and has a good solution, I for one would be eternally grateful.
这篇关于FastMM4，DebugGetMem中偶尔访问冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
