Existe um limite aceitável para vazamentos de memória?

Question

Eu apenas comecei a experimentar com SDL em C ++, e eu pensei que a verificação de vazamentos de memória regularmente pode ser um bom hábito para formar logo no início.

Com isto em mente, eu estive correndo os programas 'Hello World' através Valgrind para pegar qualquer vazamento, e embora eu tenho tudo removidos, exceto a maioria dos SDL_Init() e SDL_Quit() afirmações básicas, Valgrind ainda relata 120 bytes perdidos e 77k ainda acessível.

A minha pergunta é: Existe um limite aceitável para vazamentos de memória, ou devo esforçar para tornar todo o meu código totalmente livre de vazamento?

Answer 1

Tenha cuidado para que Valgrind não está pegando falsos positivos em suas medições.

Muitas implementações ingênuas de analisadores de memória sinalizar memória perdida como uma fuga quando não é verdade.

Talvez ter uma leitura de alguns dos papéis na seção de links externos do href="http://en.wikipedia.org/wiki/IBM_Rational_Purify" rel="noreferrer"> artigo . Eu sei que a documentação que vem com Purify descreve vários cenários onde você começa falsos positivos quando se tenta detectar vazamentos de memória e, em seguida, passa a descrever as técnicas Purify usa para contornar os problemas.

BTW eu não estou filiado a IBM de forma alguma. Acabei utilizado Purify extensivamente e irá atestar sua eficácia.

Edit: Aqui está um excelente artigo introdutório memória cobrindo monitoramento. É Purify específico, mas a discussão sobre os tipos de erros de memória é muito interessante.

HTH.

aplausos,

Rob

Answer 2

Você tem que ter cuidado com a definição de "vazamento de memória". Algo que é alocado uma vez na primeira utilização, e libertou ao sair do programa, por vezes, ser mostrado por um vazamento detector, porque começou a contagem antes que primeiro uso. Mas não é um vazamento (embora possa ser mau design, uma vez que pode haver algum tipo de global).

Para ver se um determinado pedaço de vazamentos de código, você pode razoavelmente executá-lo uma vez, em seguida, limpar o vazamento detector, em seguida, executá-lo novamente (isso, claro, requer controle programático do detector de vazamento). Coisas que "vazam" uma vez por executar do programa normalmente não importam. Coisas que "vazar" cada vez que são executados normalmente fazem questão eventualmente.

Eu raramente achei muito difícil chegar a zero nessa métrica, o que equivale a observar o uso de memória rastejando ao contrário de blocos perdidos. Eu tinha uma biblioteca, onde ele ficou tão complicadas, com caches e móveis UI e outros enfeites, que eu só corri minha suíte de teste três vezes, e ignorou qualquer "vazamentos" o que não ocorreu em múltiplos de três blocos. Eu ainda pego todos ou quase todos os vazamentos reais, e analisados ??os relatórios complicados, uma vez que eu tenho a fruta-pendurado baixo para fora do caminho. É claro que as desvantagens de usar o conjunto de testes para este fim são (1) você só pode usar as partes que não necessitam de um novo processo, e (2) a maioria dos vazamentos que você encontra são culpa do código de teste , e não o código da biblioteca ...

Answer 3

Viver com vazamentos de memória (e outras questões descuidados) é, no seu melhor, (na minha opinião) muito ruim de programação. Na pior das hipóteses torna inutilizável software.

Você deve evitar apresentá-los em primeiro lugar e executar as ferramentas que você e outros têm mencionados para tentar detectá-los.

Evite programação desleixado - há bastante programadores ruins lá fora já -. O mundo não precisa de outra

Editar

Eu concordo - muitas ferramentas podem fornecer falsos positivos

.

Answer 4

Se você está realmente preocupado com o vazamento de memória, você vai precisar fazer alguns cálculos.

Você precisa testar o seu pedido de como, de uma hora e, em seguida, calcular a memória vazada. Dessa forma, você obter um bytes de memória vazaram / valor minuto.

Agora, você vai precisar para estimar a duração média da sessão do seu programa. Por exemplo, para notepad.exe, 15 minutos soa como uma boa estimativa para mim.

Se ( duração média da sessão) * (bytes vazaram / minuto)> 0,3 * (espaço de memória normalmente ocupado pelo seu processo) , então você provavelmente deve fazer mais alguns esforços para reduzir vazamentos de memória. Eu só fiz até 0,3, use o bom senso para determinar o seu limite aceitável.

Lembre-se que um aspecto importante de ser um programador é ser um engenheiro de software, e muitas vezes Engenharia é sobre como escolher o menos pior opção de duas ou mais opções ruins. Maths vem sempre útil quando você precisa para medir o quão ruim uma opção é realmente.

Answer 5

Para uma aplicação desktop, pequenos vazamentos de memória não são um problema real. Para serviços (servidores) há vazamentos de memória são aceitáveis.

Answer 6

A maioria dos sistemas operacionais (incluindo o Windows) vai dar a volta toda de memória alocada de um programa quando o programa é descarregado. Isto inclui qualquer memória que o programa em si pode ter perdido a noção.

Tendo em conta que, a minha teoria habitual é que é perfeitamente possível vazamento de memória durante a inicialização, mas não OK para fazê-lo durante o tempo de execução.

Então, realmente a questão não é se você está vazando qualquer memória, é se você está vazando continuamente durante a execução do seu programa. Se você uso seu programa por um tempo, e não importa o que você faz que permanece em 120 bytes perdidos em vez de aumentar, eu diria que você tem feito grande. Seguir em frente.

Answer 7

Depende da sua aplicação. Alguns vazamento pode ser inevitável (devido ao tempo necessário para encontrar o vazamento V.S. prazos). Contanto que seu aplicativo pode ser executado, desde que você quer, e não tomar uma quantidade louca de memória em que o tempo é provavelmente bem.

Answer 8

Ele se parece com desenvolvedores SDL não usar Valgrind, mas eu basicamente só se preocupam com esses 120 bytes perdidas.

Com isto em mente, eu estive correndo os programas 'Hello World' através Valgrind para pegar qualquer vazamento, e embora eu tenho tudo removido, exceto o SDL_Init mais básico () e SDL_Quit () declarações, Valgrind ainda relata 120 bytes perdidos e 77k ainda acessível.

Bem, com Valgrind, "ainda memória acessível" é muitas vezes não é realmente vazou memória, especialmente em um programa tão simples. Posso apostar com segurança que basicamente não há alocação em SDL_Quit (), de modo que os "vazamentos" são estruturas apenas alocados uma vez por SDL_Init ().

Tente adicionar um trabalho útil e ver se esses montantes aumentar; tente fazer um ciclo de trabalho útil (como criar e destruir alguma estrutura SDL) e ver se a quantidade de fugas aumenta com a quantidade de iterações. Neste último caso, você deve verificar os rastreamentos de pilha dos vazamentos e corrigi-los.

Caso contrário, essas 77K fugas de contar como "memória que deve ser liberado no final do programa, mas para o qual eles contam com o sistema operacional para libertá-la.

Então, na verdade, estou mais preocupado agora por esses 120 bytes, se eles não são falsos positivos, e eles geralmente são poucos. Os falsos positivos com Valgrind são principalmente casos onde o uso de memória não inicializada se destina (por exemplo, porque ele é realmente preenchimento).

Answer 9

Como por comentários Rob Wells no Purify, faça o download e experimentar algumas das outras ferramentas lá fora. Eu uso BoundsChecker e AQTime, e ter visto diferentes falsos positivos, tanto ao longo dos anos. Note-se que o vazamento de memória pode também estar em um componente de terceiros, que você pode querer excluir de sua análise. De exemplo, MFC teve um número de vazamentos de memória nas versões primeira vista.

IMO, vazamentos de memória devem ser rastreados para qualquer código que está entrando em uma base de código que podem ter uma vida longa. Se você não consegue encontrá-los, pelo menos, fazer uma nota de que eles existem para o próximo usuário do mesmo código.

Answer 10

vazamentos de memória Firstable são apenas um problema sério quando eles crescem com o tempo, caso contrário, o aplicativo só parece um pouco maior do lado de fora (obviamente há um limite, também aqui, daí o 'sério'). Quando você tem um vazamento que cresce com o tempo que você pode estar em apuros. Quantos problemas depende das circunstâncias embora. Se você sei , onde a memória está indo e pode ter certeza que você sempre tem memória suficiente para executar o programa e tudo mais nessa máquina você ainda são um pouco fina. Se você não sabe onde a memória está indo no entanto, eu não iria enviar o programa e continuar cavando.

Answer 11

Com SDL no Linux em particular, parece haver algum vazamento na biblioteca X windows subjacente. Não há nada que você possa fazer sobre aqueles (a menos que você quer para tentar corrigir a biblioteca em si, o que provavelmente não é para o fraco hearted).

Você pode usar o mecanismo de supressão do valgrind (veja --suppressions e --gen-supressões na página man valgrind) para dizer que não incomodá-lo com esses erros.

Em geral nós temos que ser um pouco mais tolerante com bibliotecas de terceiros; enquanto nós absolutamente não deveria aceitar vazamentos de memória em nosso próprio código, e a presença de vazamentos de memória deve ser um fator na escolha entre bibliotecas de terceiros alternativas, às vezes não há escolha, mas para ignorá-los (embora possa ser uma boa idéia para relatá-los para o mantenedor da biblioteca).