¿Qué tan importante es arreglar las pérdidas de memoria?

Valgring descubrió que algunos programas GTK + pierden memoria. ¿Qué tan importante es arreglar esas fugas? Quiero decir, a menudo esos programas funcionan muy bien, pero por otro lado, uno nunca puede estar seguro si quiere copiar parte del código que se escapa a otro programa. Y no estoy seguro de si la idea de los programas GTK + es trabajar rápido y, por lo tanto, hay fugas.

Entonces, si a veces encuentro una pérdida de memoria en un programa de código abierto, ¿debería solucionarlo o hay, por ejemplo, problemas de eficiencia y, por lo tanto, la idea original de los programadores era escribir un pequeño código de fuga?

La importancia de corregir las pérdidas de memoria depende de la gravedad del problema y qué más tiene que hacer es importante. Mi experiencia es que las pequeñas pérdidas de memoria tienden a ser bastante benignas para la mayoría de las aplicaciones. La vida útil de una sesión de aplicación de escritorio no suele ser lo suficientemente larga como para ver una degradación por una pequeña pérdida de memoria.

Si está escribiendo un servidor que funciona las 24 horas, los 7 días de la semana, las pequeñas pérdidas de memoria pueden acumularse con el tiempo y convertirse en un problema importante. Pero es por eso que muchas compañías programan sus servidores para que se reinicien diariamente o semanalmente. El esfuerzo por encontrar pérdidas de memoria a menudo es excesivo en relación con lo que se puede obtener, por lo que es más fácil reiniciar los servidores de forma regular y pasar a cosas más importantes.

Para programas de ejecución corta, las pérdidas de memoria no son tan importantes; el sistema operativo reclamará todo al finalizar, pero puede causar que otros recursos no se liberen.

Sin embargo, el funcionamiento corto es relativo, una fuga puede perder el control en pocas horas o acumularse durante semanas sin ser notada.

Mi consejo es archivar un error en el rastreador con una solución propuesta, si al líder le importa, lo solucionará.

El tipo de fuga también es importante. Es posible que la asignación que se filtra sea una asignación única en la que el desarrollador confió deliberadamente en el sistema operativo para la limpieza. Estos darán un falso positivo en valgrind.

En mi opinión ciertamente dogmática sobre este tema, no hay excusas para las fugas físicas, al menos en cualquier biblioteca que pretenda ser ampliamente aplicable. Así que buscaría molestar a los desarrolladores de GTK + hasta que lo arreglen ellos mismos.

Es lo suficientemente trivial como para que una biblioteca registre atexitdevoluciones de llamada para liberar cualquier memoria que asigne al menos al descargarla. Si quiere evitar el gasto de un montón de asignaciones pequeñas, no debería estar haciéndolas en primer lugar.

Incluso el programa más perezoso que solo quiere asignar una gran cantidad de pequeños fragmentos de memoria a la vez podría usar un asignador secuencial directo que simplemente purga toda la memoria en el apagado. Si el asignador ni siquiera quiere lidiar con la alineación, puede rellenar cada fragmento que agrupa a los límites máximos de alineación. Si pudo beneficiarse con tiempos de apagado más rápidos al no liberar todos esos pequeños fragmentos de memoria individualmente, también se beneficiaría mucho simétricamente a cambio de un esfuerzo trivial al usar un asignador secuencial que agrupa la memoria de forma secuencial directa con asignaciones mucho más rápidas quemallocy patrones de memoria más amigables con la caché, solo para tener todos los grandes bloques de memoria contigua agrupados por el asignador liberados cuando se termina la biblioteca. Todo lo que la biblioteca tiene que hacer es reemplazar sus mallocllamadas por las cuales no se molestan freecon algo como seq_malloc, y llamar seq_purgeen una atexitdevolución de llamada para liberar toda la memoria asignada al descargarla.

De lo contrario, obtendrá esta desagradable biblioteca abarrotando los mensajes en sus herramientas de detección de pérdida de memoria que ahora tiene que filtrar. Peor aún, si no los filtra sistemáticamente, podrían ocultar las fugas en su propia aplicación y sus colegas podrían desarrollar el hábito de pasarlas por alto, reduciendo la utilidad de las herramientas de detección de fugas en primer lugar para evitar que su propio equipo empujando código con fugas. Es asqueroso y feo y, sobre todo, no creo que los argumentos a favor de hacer esto deliberadamente sean convincentes, dado lo trivial que es usar la solución anterior.

Las fugas lógicas (el tipo más complejo que incluso la recolección de basura no puede proteger) son un problema más complejo, y allí podría encontrar alguna justificación para que los programas de corta duración tengan fugas lógicas siempre que purguen toda la memoria que asignaron en apagado, ya que requiere una gran reflexión sobre la gestión de recursos para evitar fugas lógicas (posiblemente más en lenguajes que tienen GC). Pero no encuentro ninguna excusa razonable para evitar fugas físicas dado lo triviales que son para evitar incluso en los contextos más flojos.

De todos modos, al menos filtraría las filtraciones en valgrind para que al menos no interfieran con la capacidad de su equipo para detectar la suya.

FWIW, si un usuario informara una fuga en una aplicación en la que trabajo, estaría muy inclinado a solucionarlo (¡especialmente si incluían código para la corrección en el informe de error!). Dicho esto, puede que no ocurra de inmediato si la fuga es pequeña y otros problemas son más apremiantes (por ejemplo, un error que ocurre con frecuencia) Pero definitivamente lo apreciaría y trabajaría para solucionarlo eventualmente. Definitivamente deberías hacérselo saber. Lo apreciarán y trabajarán para solucionarlo (muy probablemente), o no les importará y todo lo que le habrá costado es algún tiempo.