Occasional access violation in FastMM4, DebugGetMem

Question

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.

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;

The exception is:

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

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).

I'm using FullDebugMode (obviously) and CheckHeapForCorruption options.

I've also established the following:

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.)

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?

Answer 1

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.

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.