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

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

нарушение прав доступа возникает в 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'.

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

Я использую FullDebugMode (очевидно) и CheckHeapForCorruption параметры.

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

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

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

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

6
access-violation delphi fastmm heisenbug

1 ответов

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

Это может быть довольно неприятно, что сеансы отладки прерываются таким образом. Я!--3-->имел некоторое обсуждение с Автор FastMM по смежному вопросу. Кажется, что DLL отладки FastMM предназначена для работы таким образом, вывод заключается в том, что не так много можно сделать, чтобы остановить эти внешние исключения.

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

5