FastMM4, Delphi6, утечка TApplication? - PullRequest
       38

FastMM4, Delphi6, утечка TApplication?

4 голосов
/ 11 февраля 2011

Я проверил FastMM4 с D6.Когда я отлаживал простое приложение с использованием «форм», я каждый раз получал 3 строки для утечки памяти.

У этого приложения была утечка памяти.Утечки небольшого блока (исключая ожидаемые утечки, зарегистрированные указателем):

13 - 20 байтов: TObjectList x 3, Unknown x 3 29 - 36 байтов: TWinHelpViewer x 1 37 - 52 байта: THelpManager x 1

Это нормально?

Что вызывает это?

Спасибо: дд

Ответы [ 2 ]

10 голосов
/ 11 февраля 2011

RTL / VCL, поставляемый с Delphi 6, содержит некоторые утечки памяти. В более поздних выпусках Delphi использование FastMM привело к удалению этих утечек памяти из RTL / VCL.

Вам нужно зарегистрировать эти известные и ожидаемые утечки памяти в FastMM. Как только вы зарегистрируете утечки, FastMM не сообщит о них. Хотя эти утечки являются реальными, их лучше игнорировать по разным причинам:

  • Утечка памяти в результате этих известных утечек VCL невелика и не увеличивается в течение всего жизненного цикла процесса.
  • Память возвращается в систему, как только процесс все равно завершается.
  • Так как утечки в коде находятся вне вашего контроля, вы не можете ничего сделать. Вы можете исправить их и использовать собственную версию рассматриваемых модулей VCL, но стоит ли это того?

Единственное время, когда эти утечки могут иметь значение, - это если у вас была DLL, которая загружалась и выгружалась из одного и того же процесса тысячи раз в течение времени существования этого процесса. Я не верю, что это очень реалистичный сценарий.

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

В моем проекте Delphi 6 у меня есть следующий код в моем файле .dpr:

// Register expected VCL memory leaks caused by Delphi unit HelpIntfs.
FastMM4.RegisterExpectedMemoryLeak(36, 2); // THelpManager x 1, THTMLHelpViewer x 1
FastMM4.RegisterExpectedMemoryLeak(20, 7); // TObjectList x 3, THelpSelector x 1, Unknown x 3
FastMM4.RegisterExpectedMemoryLeak(52);    // TWinHelpViewer x 1

У меня также есть следующее в TForm потомке, от которого происходят все формы в моем приложении:

var
  ExpectedHelpStringMemoryLeakRegistered: Boolean;

procedure TMyForm.WMHelp(var Message: TWMHelp);
begin
  if not (biHelp in BorderIcons) and not ExpectedHelpStringMemoryLeakRegistered then begin
    // Register expected VCL memory leaks caused by Delphi unit HelpIntfs.
    FastMM4.RegisterExpectedMemoryLeak(44); // TString x 1
    ExpectedHelpStringMemoryLeakRegistered := True;
  end;
  inherited;
end;

В зависимости от того, какие именно устройства вы используете в RTL / VCL и как вы их используете, вам может потребоваться зарегистрировать различные утечки памяти.

1 голос
/ 11 февраля 2011

Я думаю, это нормально, если вы не исправили источники.IIRC, когда был «memproof», его автор «Атанас Стоянов» вел список ошибок, которые вызывали утечки памяти.Утечка в файле 'classes.pas', fi, произошла в каждом приложении VCL-форм.Хотя продукт больше не существует, список можно найти на сайте Automated QA.Вот список для D6 .

...