Geek Answers Handbook

Accidental Access Violation in FastMM4, DebugGetMem

I am trying to track access violation. Reproducibility seems non-deterministic and rare, so I want to test some of my assumptions before moving on.

Access violation occurs in FastMM4 version 4.991 in the DebugGetMem function 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 the exception class $ C0000005 with the message "Access violation at address 0x01629099: reading address 0x66aed8f8".

The call stack is usually the same. It is called from a drawing event in a virtual tree view in which I call Format('%s %s %s', [vid, node, GetName()]) , although I doubt that this is really relevant (except that Format allocates dynamic memory).

I am using FullDebugMode (obviously) and CheckHeapForCorruption .

I also installed the following:

  1. Enabling CatchUseOfFreedInterfaces does not show anything new. I still get the same access violation, and no further diagnostics.
  2. I once reproduced an FullDebugModeScanMemoryPoolBeforeEveryOperation := True using FullDebugModeScanMemoryPoolBeforeEveryOperation := True , although I can’t remember if CatchUseOfFreedInterfaces turned on or off in this case.
  3. This is not a concurrency issue; my application is single threaded. (Actually, this is not entirely true. I am using Virtual TreeView, which creates a hidden workflow, but if this is really the reason, then the error is in Virtual TreeView and not in my code, which is rather unlikely.)

Do I believe that, despite the fact that CheckHeapForCorruption does not intercept anything, this exception can only be related to the fact that my code damaged a bunch? Is there anything else that could cause FastMM4 to crash this way?

Any suggestions for further diagnosis, or even make the failure more reproducible?

+9
source share
2 answers

Oddly enough, this is normal behavior. If you switch to the CPU view, you will see that the instruction pointer is inside the FastMM_FullDebugMode.dll module. Some of FastMM's debugging features may, at its discretion, cause access violations. If you continue to run, you will find that your application is working correctly.

It can be quite frustrating that debugging sessions are interrupted in this way. I had some discussion with the author of FastMM on a related issue. It seems that the FastMM debugging DLL is designed in such a way that the conclusion is that there is not much that could be done to stop these external exceptions from occurring.

If someone out there acknowledges this frustration and has a good solution, I would always be grateful.

+7
source

Possible fix:

https://github.com/pleriche/FastMM4/issues/81

Just like that: The body must be at least 30 characters; You are logged in 14.

0
source

More articles:


All Articles