Resposta ao Desafio da Semana #1 [Memory Leak - C/C++]

Article
04/21/2006

Por: Roberto A. Farah

Um cliente contactou você porque uma aplicação C aparenta estar consumindo memória sem nunca liberá-la. Seu objetivo é de certificar que o sintoma é esse mesmo, e, em seguida, identificar o problema causando esse sintoma, propor uma solução (solução prática que exija o mínimo de alterações na aplicação) e descrever as possíveis estratégias para se isolar esse problema.

Nota: Imagine que você tenha que descrever um modo de se identificar o problema de memória que seja válido para essa simples aplicação e para uma grande aplicação com milhares de linhas de código. Esse é o ponto mais importante desse desafio.

SINTOMA

Definitivamente temos um memory leak ocorrendo.

PROBLEMA

A memória dinamicamente alocada nunca é liberada pela aplicação.

A aplicação usa malloc() para alocar memória e não usa free() para liberá-la.

SOLUÇÃO

Onde há:

// Libera memoria

pbyAllocated = NULL;

Colocar:

// Libera memoria

free(pbyAllocated);

pbyAllocated = NULL;

ESTRATÉGIA

Muitas são as abordagens possíveis para se isolar o problema, digo, para se comprovar se a aplicação tem um handle ou memory leak. Eis algumas delas:

a) Revise o código. Sim, embora óbvio, para uma aplicação pequena como essa é talvez a melhor maneira de se identificar onde está o problema numa aplicação pequena. Obviamente não recomendado numa aplicação muito grande ou com muitos módulos.

b) Use o Performance Monitor. Para isso rode a aplicação e aguarde antes de pressionar uma tecla para começar. Em seguida selecione o objeto Process e a instancia da aplicação MemoryLeak.exe.

Em counters acima, selecione:

Private Bytes, Virtual Byes e Handle Count.

Essa estratégia é ótima para se identificar potenciais vazamentos de handle ou memória.

Em seguida, pressione uma tecla na janela da aplicação e observe. Você deveria obter algo como:

Note que Handle Count, que é o contador de handles usados pela aplicação, está constante, o que sugere que não há um handle leak. Se o valor estivesse aumentando, juntamente com os outros dois contadores, nos indicaria que há um handle leak. Isso ocorre, por exemplo quando você usa chamadas de API que retornam um handle e, ao final, não fecha o handle.

Observe que Private Bytes aumenta continuamente. Private Bytes, refere-se ao número de bytes alocados pela aplicação e de uso exclusivo da aplicação.

Virtual Bytes é o tamanho da memória virtual (virtual address space) que o processo está usando. O default é 2 GB.

Portanto, os contadores mostram que a aplicação não libera memória enquanto executando e que durante a execução o consumo de memória aumenta gradativamente.

Para se isolar problemas de memória em aplicações .NET é necessário se usar os contadores de memória do .NET além desses.

Também é possível se usar outros contadores para uma análise mais apurada da memória, mas, regra geral, os contadores acima serão suficientes na grande maioria dos casos. A próxima vez que você desconfiar de algum memory leak, use essa abordagem, será útil! É ótimo quando você não tem acesso ao código fonte ou quando você precisa primeiro identificar qual a aplicação causando handle/memory leak, para, depois verificar o código!

c) Outra estratégia possível seria utilizar ferramentas como UMDH (https://support.microsoft.com/kb/268343/en-us ), Gflags que vem no Debugging Tools For Windows (https://www.microsoft.com/whdc/devtools/debugging/default.mspx ), PageHeap (https://support.microsoft.com/kb/286470/en-us ) ou DebugDiag em modo de Memory e Handle Leak ( https://www.debugdiag.com )

Essas ferramentas alteram algumas chaves de registry para poder mapear alocações de memória. São úteis em casos de Heap Corruption (corrupção de memória de heap) ou Memory Leak (vazamentos de memória).

Eis os resultados de se usar DebugDiag para se isolar esse problema:

Após carregar a aplicação MemoryLeak.exe:

Isso iniciaria o DebugDiag para analisar por 15 minutos a aplicação.

O DebugDiag vai gerar um dump também, portanto, será possível se ter muita riqueza de detalhes sobre o handle/memory leak após a análise.

O mesmo pode ser feito com GFLAGS e UMDH. E esse artigo explica muito bem: https://support.microsoft.com/kb/268343/en-us

Essas ferramentas registrarão todas as chamadas de alocação de heap do processo, incluindo a pilha de chamada para cada alocação, número de alocações, etc...

Para usar o UMDH é necessário se instalar o Debugging Tools for Windows, cujo link está mais acima.

UMDH vai gerar arquivos texto com a pilha de alocação, portanto, será possível ver o ponto onde a memória está sendo alocada. Ou seja, além de saber se há um leak ou não você poderá saber qual a rotina causando o leak!

Para poupar espaço omiti as saídas.

d) Finalmente, a abordagem que considero a melhor para os desenvolvedores, pois tem o benefício de ser proativa para se achar memory leaks, ou seja, ao se testar a versão Debug da aplicação, sempre que houver um Leak ele será mostrado no Visual C++, também apontando o local que está sendo responsável por vazar memória. Portanto, se o desenvolvimento é efetuado usando essa abordagem os leaks serão detectados nos testes efetuados em desenvolvimento!

Essa abordagem usa a versão Debug do C runtime, o #include <crtdbg.h>, _CrtSetDbgFlag() e _CrtDumpMemoryLeaks().

O artigo de referência é:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vxconEnablingMemoryLeakDetection.asp

Eis a saída esperada ao executar a versão Debug no Visual C++:

Detected memory leaks!

Dumping objects ->

c:\development\my tools\blog articles\article #5\memoryleak\memoryleak\memoryleak.cpp(44) : {150} normal block at 0x025075E8, 490000 bytes long.