search

Executando a Aplicação de Teste

Ao observar mais de perto a aplicação, podemos ver que existem três procedimentos de teste diferentes para simular problemas de memória:

hashtag
Vazamentos de memória

procedure TMainForm.UniButton1Click(Sender: TObject);
var
  P : PInt64;
begin
  // Simular vazamento de memória:
  // Criamos uma instância de memória para Int64, mas não a liberamos (vazamento de memória)
  New(P);

  // A chamada abaixo encerrará o Standalone Server, então podemos ver a mensagem de erro de vazamento do FastMM imediatamente.
  // Isso é feito apenas para fins de demonstração.
  // Nunca chame "UniServerInstance.Terminate" no seu código de produção
  // Alternativamente, você pode comentar a linha abaixo e sair da aplicação manualmente.
  UniServerInstance.Terminate;
end;

No evento acima tentamos simular um vazamento de memória criando um PInt64 instância. Como vazamentos de memória são reportados apenas na saída, encerramos a aplicação imediatamente para ver a caixa de mensagem de erro:

clip0361

Ao mesmo tempo, o vazamento de memória será registrado no arquivo de log do FastMM que será criado na mesma pasta.

Aqui estão os conteúdos parciais do arquivo de log:

--------------------------------2025/5/5 16:32:07--------------------------------

Não apenas reporta a existência de um vazamento de memória, mas também registra a cadeia de métodos (rastreamento de pilha) que levou ao vazamento de memória:

Linha 46 no arquivo Main.pas — mostra a localização no código onde a memória foi alocada, mas não foi liberada:

clip0362

hashtag
Corrupção de memória

O tipo mais importante de problemas de memória são as corrupções de memória, quando uma aplicação tenta alterar uma localização de memória que foi previamente liberada.

clip0363

Novamente podemos ver o mesmo erro no arquivo de log:

--------------------------------2025/5/5 16:49:50--------------------------------

O log acima indica que o objeto de memória foi alocado na linha de código 61:

clip0364

O bloco foi previamente liberado pela thread 0x5164, e o rastreamento de pilha (endereços de retorno) no momento foi:

A memória alocada é descartada na linha 62.

Observe que o FastMM não é capaz de encontrar a linha exata do código onde a memória é alterada. O FastMM só pode detectar e relatar que uma localização de memória foi alterada depois de ter sido liberada e realocada.

AnteriorOpções FastMM4PróximoConclusão