Чи є можливість програмно визначити, чи не вивільнився FastMM конкретний блок пам'яті?

103

Я намагаюся виявити, чи не був звільнений блок пам'яті. Звичайно, менеджер мені каже, що за допомогою діалогового вікна або файлу журналу, але що робити, якщо я хотів би зберегти результати в базі даних? Наприклад, я хотів би мати в таблиці бази даних імена підпрограм, які виділяли задані блоки.

Після прочитання документації FastMM я знаю, що з версії 4.98 ми маємо можливість отримувати повідомлення від менеджера про розподіл пам’яті, звільнення та перерозподіл пам’яті в міру їх виникнення. Наприклад, OnDebugFreeMemFinishподія передає нам PFullDebugBlockHeaderякий містить корисну інформацію. Не PFullDebugBlockHeaderвистачає однієї речі - інформація, якщо даний блок було звільнено програмою.

Якщо OnDebugFreeMemFinishтільки не викликається тільки не звільнені блоки? Це я не знаю і хотів би з’ясувати.

Проблема полягає в тому, що навіть підключившись до OnDebugFreeMemFinishвипадку, я не зміг з’ясувати, звільнився блок чи ні.

Ось приклад:

program MemLeakTest;

{$APPTYPE CONSOLE}

uses
  FastMM4, ExceptionLog, SysUtils;


procedure MemFreeEvent(APHeaderFreedBlock: PFullDebugBlockHeader; AResult: Integer);
begin
//This is executed at the end, but how should I know that this block should be freed
//by application? Unless this is executed ONLY for not freed blocks.
end;

procedure Leak;
var
  MyObject: TObject;
begin
  MyObject := TObject.Create;
end;

begin
  OnDebugFreeMemFinish := MemFreeEvent;
  Leak;
end.

Чого мені не вистачає, це зворотній дзвінок:

procedure OnMemoryLeak(APointer: PFullDebugBlockHeader);

Переглянувши джерело FastMM, я побачив, що є процедура:

procedure LogMemoryLeakOrAllocatedBlock(APointer: PFullDebugBlockHeader; IsALeak: Boolean);

який можна було б відмінити, але, можливо, існує простіший спосіб?

— Водзу
джерело

Я завжди розумів, що FastMM може зробити цю перевірку лише як ДУЖЕ ОСТАННІ дії, які програма повинна зробити - за визначенням - так до моменту, коли FastMM робить свій звіт, ваш код закінчився. Щоб отримати часткове рішення, ви завжди можете заглянути в їх джерело, щоб побачити, як позначена виділена пам'ять.

— Брайан Мороз

Як повідомили, як очікується витік? Ви зареєстрували це як очікувалося. Крім того, ви не можете вирішити, що пам'ять просочується до відключення, якщо ви не надасте складну логіку, яка розуміє очікувані терміни життя.

— Девід Геффернан

Якщо OnDebugFreeMemFinishвикликається, це означає, що блок був звільнений. Немає OnMemoryLeakподії. Ніколи не могло бути такої події. Що робить FastMM, це при відключенні визначати, що будь-які блоки, які не були звільнені, повинні протікати. Він не може виявити витік раніше цього.

— Девід Геффернан

Щоразу, коли FastMM каже мені, що відбувається витік пам'яті, я вимикаю інструменти та негайно виправляю. Якщо цього не зробити, то важко буде відтворити витік. Якщо ви дійсно хочете увійти до бази даних, тоді вам потрібно буде переглянути функцію CheckBlocksOnShutdown. Ще одна можлива точка розширення, AppendEventLogале вам потрібно змінити джерело FastMM, яке я підозрюю.

— Девід Геффернан

Ерм просто підберіть файл, проаналізуйте його і помістіть у БД?

— Тоні Хопкінсон,

Навіть якщо такий обробник існує, це було б майже марно, оскільки все, включаючи БД, було б закрито в той час, коли FastMM повідомляє про витоки.

Отже, я пропоную вам увімкнути LogErrorsToFileразом з FullDebugModeумовами в FastMM4Options.inc. Це дасть вам текстовий файл із протіканнями, який згодом ви зможете проаналізувати та помістити в БД.

— Сергій Хейлик
джерело