¿Cómo probar las fugas de memoria?

Question

Tenemos una aplicación con cientos de posibles acciones de usuario y pensamos en cómo mejorar las pruebas de detección de fugas de memoria.

Actualmente, así es como sucede: cuando se prueba manualmente el software, si parece que nuestra aplicación consume demasiada memoria, utilizamos una herramienta de memoria, buscamos la causa y la solucionamos. Es un proceso bastante lento y no eficiente: los problemas se descubren tarde y depende de la buena voluntad de un desarrollador.

¿Cómo podemos mejorar eso?

• Compruebe internamente que algunas acciones (como "cerrar archivo") recuperan algo de memoria y lo registran?
• ¿Afirmar el estado de la memoria dentro de nuestras pruebas unitarias (pero parece que esto sería una tarea tediosa)?
• ¿Lo verifica regularmente de vez en cuando?
• ¿Incluye ese cheque cada vez que se implementa una nueva historia de usuario?

Answer 1

En mi empresa, hemos programado una ruta de acción infinita para nuestra aplicación. El recolector de basura de Java debe limpiar todos los mapas no utilizados y la lista y algo así. Así que dejamos que la aplicación comience con la ruta de acción sin fin y observemos si el tamaño de uso de memoria está creciendo.

La comprobación de qué campos no se eliminan puede utilizar JProfiler para Java.

Answer 2

¿Qué idioma?

Usaría una herramienta como Valgrind, trataré de ejercitar completamente el programa y ver de qué informa.

Answer 3

primera línea de defensa:

• lista de control con memoria común errores de asignación relacionados para desarrolladores
• directrices de codificación

segunda línea de defensa:

• código Evaluaciones
• analyis código estático (como parte del proceso de construcción)
• memoria de perfiles de herramientas

Si trabaja con el lenguaje no administrado (como C/C++) que puede eficientemente descubrir la mayor parte de las pérdidas de memoria mediante el secuestro de gestión de memoria funciones. Por ejemplo, puede rastrear todas las asignaciones/desasignaciones de memoria.

Answer 4

Me parece que el núcleo del problema no es tanto encontrar pérdidas de memoria como saber cuándo probarlas. Usted dice que tiene muchas acciones de usuario, pero no dice qué secuencias de acciones de usuario son significativas. Si puedes generar secuencias significativas al azar, discutiría mucho para las pruebas aleatorias.En las pruebas aleatorias que mediría

• cobertura de código (con gcov o valgrind)
• Uso de memoria (con valgrind)
• cobertura de las acciones de los usuarios mismos

Por "cobertura de las acciones de los usuarios "Me refiero a declaraciones como las siguientes:

• F o cada par de acciones A y B, si hay una secuencia significativa de acciones en donde A es seguido inmediatamente por B, entonces hemos probado tal secuencia.

Si no es así, entonces puede preguntar qué fracción de pares A y B es verdadera.

Si tiene los ciclos de CPU para pagarlo, probablemente también se beneficie al ejecutar valgrind u otra herramienta de comprobación de memoria antes de cada confirmación en su repositorio de código fuente o durante una compilación nocturna.

¡Automatizar!

Answer 5

Reemplazar nueva y eliminar con sus versiones personalizadas y registrar cada acto de asignación/desasignación.

Hablando en general (no sobre pruebas, sino para combatir el problema en su origen), los smartpointers ayudan a evitar este problema. Afortunadamente, el estándar C++ 11 proporciona nuevas clases convenientes de punteros inteligentes (shared_ptr, unique_ptr).