Случайное нарушение доступа в FastMM4, DebugGetMem

Question

Я пытаюсь отследить нарушение прав доступа. Воспроизводимость кажется недетерминированной и редкой, поэтому я хочу проверить некоторые из моих предположений, прежде чем идти дальше.

Нарушение прав доступа возникает в FaseMM4 версии 4.991, в функции DebugGetMem, в следующем коде:

  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 raised exception class $C0000005 with message 'access violation at 0x01629099: read of address 0x66aed8f8'.

Стек вызовов обычно одинаков. Он вызывается из события рисования на виртуальном дереве, в котором я вызываю Format('%s %s %s', [vid, node, GetName()]) хотя я сомневаюсь, что это действительно актуально (кроме этого Формат выделяет динамическую память).

я использую FullDebugMode (очевидно) и CheckHeapForCorruption опции.

Я также установил следующее:

1. Включение CatchUseOfFreedInterfaces ничего нового не показывает Я все еще получаю то же самое нарушение прав доступа, и никакой дополнительной диагностики.
2. Я однажды воспроизвел аварию с FullDebugModeScanMemoryPoolBeforeEveryOperation := Trueхотя не могу вспомнить CatchUseOfFreedInterfaces был включен или выключен по этому случаю.
3. Это не проблема параллелизма потока; мое приложение однопоточное. (На самом деле, это не совсем так. Я использую Virtual TreeView, который создает скрытый рабочий поток, но если это действительно причина, то ошибка в Virtual TreeView, а не в моем коде, что довольно маловероятно.)

Правильно ли я думаю, что, несмотря на CheckHeapForCorruption ничего не поймав, это исключение может быть только из-за того, что мой код повредил кучу? Есть ли что-нибудь еще, что может привести к сбою FastMM4 таким образом?

Любые предложения для дальнейшей диагностики, или даже сделать сбой более воспроизводимым?

Answer 1

Как ни странно, это нормальное поведение. Если вы переключитесь в представление CPU, вы увидите, что указатель инструкций находится внутри модуля FastMM_FullDebugMode.dll. Некоторые функции отладки FastMM могут спровоцировать нарушения доступа. Если вы продолжите выполнение, вы обнаружите, что ваше приложение работает правильно.

Может быть довольно неприятно, что сеансы отладки прерываются таким образом. У меня было некоторое обсуждение с автором FastMM по связанной проблеме. Кажется, что DLL-библиотека отладки FastMM разработана для такой работы, и вывод состоит в том, что не так много можно сделать, чтобы остановить возникновение этих внешних исключений.

Если кто-то там признает это разочарование и найдет хорошее решение, я, например, буду вечно благодарен.