2010-08-24 12 views
5

Acabo de resolver una pérdida de memoria en mi aplicación y ahora quiero escribir una prueba de unidad para garantizar que esto no vuelva a suceder.prueba de unidad de fuga de memoria C++

Estoy buscando una manera de detectar el uso de la memoria de la aplicación actual (conjunto de trabajo), antes y después de algunas funciones.

Por ejemplo:

long mem_used= GetMemUsed(); 
/* Do some work */ 
/* clean up */ 

if(mem_used != GetMemUsed()) { 
    Error("Memory leek"); 
} 

he encontrado un montón de maneras de detectar el uso de la memoria a través de todo el sistema, pero no sólo por la aplicación actual.

¿Sugerencias, enlaces, fragmentos de código?

+1

Escriba la prueba unitaria antes de corregir el error. –

+0

¿Cuál es la plataforma/compilador aquí? –

+0

@Steve Townsend - VS2008 Windows, se olvidó de mencionar eso. –

Respuesta

6

Boost.Test le dirá automáticamente al final de una ejecución de prueba si alguna de las pruebas de su unidad ha filtrado la memoria.

No sé si alguno de los otros marcos de prueba de unidades de C++ ofrece este tipo de funcionalidad.

+2

Compatibilidad con fugas de memoria solo en compiladores de MS: http://www.boost.org/doc/libs/1_44_0/libs/test/doc/html/execution-monitor/user-guide.html –

6

Me gusta mucho ValGrind para este tipo de cosas. Estas herramientas ya existen; no necesita escribir sus propias pruebas unitarias para detectar fugas de memoria.

+1

Solo asegúrese de que esté integrado en la prueba unitaria. Tener que ejecutar valgrind a mano para validar la aplicación dará lugar a personas perezosas que no ejecuten la prueba. –

+0

Eso suena como un problema de personal, no como un problema de software. –

+0

@Ed: la pereza es un problema de persona, estamos de acuerdo, pero ya que está prevenido, tómelo en cuenta y, como sugiere Martin, hágalo de modo que la forma más fácil de ejecutar la prueba sea también aquella en la que la pérdida de memoria la detección está construida :) –

3

Eso no es una prueba de unidad. Si quiere asegurarse de que alguna unidad que se supone gestione un recurso no pierda ese recurso, entonces debe validar que el recurso que administra se elimina en el momento correcto. Puede hacer esto con objetos simulados que incrementan un contador en la construcción y decrementan en eliminar ... luego asegúrese de que el recuento sea correcto.

Una prueba que verifica el uso de memoria de una aplicación completa no es algo para una prueba unitaria. Las pruebas unitarias son para unidades particulares dentro de la aplicación.

+0

¿Qué es "eso"? en "¿Eso no es una prueba de unidad"? ¿Ejecutando ValGrind? ¡Gracias por la sugerencia de objeto falsa contada! – Technophile

+0

Probar una aplicación completa no es una prueba unitaria. –

3

Para Linux u otros sistemas que utilizan GLibC hay functions para obtener estadísticas de asignación de memoria. Suponiendo que no haya asignaciones diferidas, debe tener la misma memoria comprometida con malloc antes y después de realizar su prueba.

+1

El OP preguntaba por C++. malloc no debe usarse en un contexto de C++. – anthropomorphic

+0

@Michael, esto es cierto desde la perspectiva de un programador, pero probablemente encontrará que la biblioteca estándar de C++ define 'new' para usar malloc bajo el capó. La estadística de Malloc probablemente todavía sea relevante para la detección de fugas. – doron

+0

probablemente? Me gustaría saberlo con certeza antes de asumir algo. – anthropomorphic

0

También puede utilizar marco de pruebas Google (gtest) y luego usar las herramientas de rendimiento de Google (gperf) para encontrar fugas. GPerf pone en una biblioteca de memoria de reemplazo y si se encuentra una pérdida de memoria después de que finalice la ejecución de la prueba, se lo hará saber y le dará un comando pprof para ejecutar con varios formatos de salida diferentes: texto, punto, web, etc. Esta herramienta encontrar fugas tanto en las pruebas como en el código de producción.

También uso Valgrind para confirmar si hay una fuga cuando es cuestionable pero prefiero gperf. Una sorpresa es que si ha compilado con la biblioteca de memoria gperf y trata de usar Valgrind, no encontrará ningún problema porque detecta las fugas, por lo que debe limpiar la compilación entre cambios o tener una segunda copia del proyecto.