Qual a importância de corrigir vazamentos de memória?

Descobri por Valgring que alguns programas GTK + vazam memória. Quão importante é consertar esses vazamentos? Quero dizer, geralmente esses programas funcionam muito bem, mas por outro lado, nunca se pode ter certeza se deseja copiar parte do código que vazou para outro programa. E não tenho certeza se a idéia dos programas GTK + é trabalhar rápido e, portanto, há vazamentos.

Portanto, se às vezes encontro um vazamento de memória em um programa de código aberto, devo corrigi-lo ou existem, por exemplo, problemas de eficiência e, portanto, a idéia original dos programadores era escrever um pequeno código de vazamento?

A importância de corrigir vazamentos de memória depende da gravidade do problema e o que mais você precisa fazer é importante. Minha experiência é que pequenos vazamentos de memória tendem a ser bastante benignos para a maioria dos aplicativos. A vida útil de uma sessão de aplicativo de desktop geralmente não é longa o suficiente para ver qualquer degradação causada por um pequeno vazamento de memória.

Se você estiver escrevendo um servidor que funciona 24/7, pequenos vazamentos de memória podem aumentar com o tempo e se tornar um grande problema. Mas é por isso que muitas empresas agendam seus servidores para reiniciar diariamente ou semanalmente. O esforço para encontrar vazamentos de memória geralmente é excessivo em relação ao que pode ser ganho, por isso é mais fácil reiniciar os servidores regularmente e passar para coisas mais importantes.

Para programas de execução curta, vazamentos de memória não são tão importantes; o sistema operacional recuperará tudo na finalização, mas poderá causar a liberação de outros recursos.

Por mais que o curto prazo seja relativo, um vazamento pode sair de controle em poucas horas ou se acumular por semanas despercebidas.

Meu conselho é registrar um bug no rastreador com uma correção proposta, se o líder se importar, ele o corrigirá.

O tipo de vazamento também é importante. É possível que a alocação que vaza seja uma alocação única, na qual o desenvolvedor tenha deliberadamente confiado no sistema operacional para a limpeza. Isso dará um falso positivo ao valgrind.

Na minha opinião dogmática sobre esse assunto, não há desculpas para vazamentos físicos, pelo menos em qualquer biblioteca que pretenda ser amplamente aplicável. Então, eu procuraria incomodar os desenvolvedores do GTK + até que eles próprios consertassem.

É trivial o suficiente para uma biblioteca registrar atexitretornos de chamada para liberar qualquer memória alocada pelo menos ao ser descarregada. Se quiser evitar a despesa de um barco cheio de alocações pequeninas, não deveria fazê-las em primeiro lugar.

Mesmo o programa mais preguiçoso que apenas deseja alocar um monte de pequenos pedaços de memória de uma só vez pode usar um alocador sequencial direto que apenas elimina toda a memória no desligamento. Se o alocador nem quiser lidar com o alinhamento, ele poderá preencher cada pedaço único que ele agrupa até os limites máximos de alinhamento. Se ele foi capaz de se beneficiar com tempos de desligamento mais rápidos, não liberando todos esses pequenos pedaços de memória individualmente, também se beneficia bastante simetricamente em troca de um esforço trivial, usando um alocador sequencial que agrupa a memória de maneira sequencial direta com alocações muito mais rápidas quemalloce padrões de memória mais amigáveis ​​ao cache, apenas para liberar todos os grandes blocos de memória contígua agrupados pelo alocador quando a biblioteca estiver concluída. Tudo o que a biblioteca precisa fazer é substituir suas mallocchamadas pelas quais elas não se importam freecom algo assim seq_malloce chamar seq_purgeum atexitretorno de chamada para liberar toda a memória alocada após o descarregamento.

Caso contrário, você terá essa biblioteca desagradável repleta de mensagens em suas ferramentas de detecção de vazamento de memória, agora você precisa filtrar. Pior, se você não filtrá-los sistematicamente, eles podem obscurecer os vazamentos em seu próprio aplicativo e seus colegas podem desenvolver o hábito de ignorá-los, reduzindo a utilidade das ferramentas de detecção de vazamentos em primeiro lugar para impedir que sua própria equipe empurrando código com vazamento. É grosseiro e feio e, acima de tudo, não acho os argumentos a favor de fazê-lo deliberadamente serem convincentes, dado o quão trivial é usar a solução acima.

Vazamentos lógicos (o tipo mais complexo que nem a coleta de lixo pode proteger) são uma questão mais complexa, e lá encontrei uma justificativa para que programas de curta duração tenham vazamentos lógicos, desde que purgem toda a memória que alocaram em desligamento, pois requer muita reflexão sobre o gerenciamento de recursos para evitar vazamentos lógicos (sem dúvida mais nos idiomas que possuem GC). Mas não encontro nenhuma desculpa razoável para evitar vazamentos físicos, dada a trivialidade de evitar mesmo nos contextos mais preguiçosos.

De qualquer forma, pelo menos eu filtraria os vazamentos em valgrind para que eles pelo menos não mexessem na capacidade da sua equipe de detectar a sua.

FWIW, se um usuário relatasse um vazamento em um aplicativo em que trabalho, eu estaria muito inclinado a corrigi-lo (especialmente se eles incluíssem código para a correção no relatório de erros!). Dito isto, pode não acontecer imediatamente se o vazamento for pequeno e outros problemas forem mais urgentes (por exemplo, um bug que ocorre com frequência). Mas eu definitivamente apreciaria e trabalharia para corrigi-lo eventualmente. Você definitivamente deveria deixá-los saber. Eles irão apreciá-lo e trabalharão para corrigi-lo (provavelmente), ou não se importarão e tudo o que terá custado a você é algum tempo.