title: Occasional access violation in FastMM4, DebugGetMem
body: <p>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.</p>
  
  <p>The access violation is raised in FastMM4, version 4.991, in the function <code>DebugGetMem</code>, in the following code:</p>
  
  <pre><code>if (ASize &gt; (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;
  </code></pre>
  
  <p>The exception is:</p>
  
  <blockquote>
    <p>Project Workstation.exe raised exception class $C0000005 with message 'access violation at 0x01629099: read of address 0x66aed8f8'.</p>
  </blockquote>
  
  <p>The call stack is usually the same. It's being called from a paint event on the virtual treeview in which I call <code>Format('%s %s %s', [vid, node, GetName()])</code> though I doubt that is really relevant (other than that Format allocates dynamic memory).</p>
  
  <p>I'm using <code>FullDebugMode</code> (obviously) and <code>CheckHeapForCorruption</code> options.</p>
  
  <p>I've also established the following:</p>
  
  <ol>
  <li>Turning on <code>CatchUseOfFreedInterfaces</code> doesn't show anything new. I still get the same access violation, and no additional diagnostics.</li>
  <li>I once reproduced the crash with <code>FullDebugModeScanMemoryPoolBeforeEveryOperation := True</code>, although I can't remember whether <code>CatchUseOfFreedInterfaces</code> was on or off on this occasion.</li>
  <li>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.)</li>
  </ol>
  
  <p>Am I right in thinking that, despite <code>CheckHeapForCorruption</code> 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?</p>
  
  <p>Any suggestions for further diagnostics, or even making the crash more reproducible?</p>