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.

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

The access violation is raised in FastMM4, 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 引发异常类 $C0000005，并显示消息0x01629099 处的访问冲突:读取地址 0x66aed8f8".

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

调用栈通常是一样的.它是从虚拟树视图上的绘制事件中调用的，我在其中调用 Format('%s %s %s', [vid, node, GetName()]) 尽管我怀疑这是否真的相关(除此之外 Format 分配动态内存).

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.

我还确定了以下内容:

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

1. Turning on CatchUseOfFreedInterfaces doesn't show anything new. I still get the same access violation, and no additional diagnostics.
2. I once reproduced the crash with FullDebugModeScanMemoryPoolBeforeEveryOperation := True, although I can't remember whether CatchUseOfFreedInterfaces was on or off on this occasion.
3. 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屋！