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?

Cruise

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.

Evelynneven

I'm wondering whether I have ever tried to continue execution after such an exception. Now I have to wait for the error to happen again, and then to try. If this works (i.e. is applicable to my case) then I will be eternally grateful! I will post an update as soon as I know. (It could be several days, or even weeks.) – Cruise

Yup. I got one just now, continued execution, and apparently everything is fine. Oh well, only two days wasted on this 'problem'. Thanks, David. – Cruise

To sum this up: just ignore the AV? – Tereus

@SolarWind Yup, after a while you will be used to it and recognise it – Evelynneven

I see that the bug was reported in 2012 but it is still present. I think it will not be fixed so soon, so yes, we should get used with it :) The problem (now passed for me) is all that time spend to debug MY code :) (: for nothing. – Tereus

@SolarWind Yes, it's quite frustrating until you realise that there's nothing wrong with your code! – Evelynneven

So, the test method is: After we see the AV in debugger, press F9 to continue program execution. If no crash, then we know we hit the "107209" bug. – Tereus

@SolarWind The debugger breaks at the same point every time and you just come to recognise it. That's how it is for me. – Evelynneven