c++ - how - ¿Detección de fugas de memoria GCC equivalente a Microsoft crtdbg.h?

use valgrind to find memory leaks

Question

Después de muchos años de trabajar en una biblioteca de C ++ de propósito general con el compilador Microsoft MSVC en Visual Studio, ahora lo estamos portando a Linux / Mac OS X (ruega por nosotros). Me he acostumbrado y me gusta mucho el simple mecanismo de detección de fugas de memoria en MSVC:

#ifdef DEBUG
    #define _CRTDBG_MAP_ALLOC
    #define NEW   new( _NORMAL_BLOCK, __FILE__, __LINE__)
    #include <stdlib.h>
    #include <crtdbg.h>
#else
    #define NEW   new
#endif

Cada asignación de memoria se realiza utilizando esta NUEVA macro. Cada vez que finaliza un proceso que utiliza nuestra biblioteca, las pérdidas de memoria (bloques que no se han desasignado) se notifican en la consola junto con el archivo y la línea # donde se asignó originalmente la memoria.

La parte de esto que me gusta es que no tengo que "ejecutar con la herramienta de rendimiento" de forma activa o indicar de otra manera que estoy buscando fugas. Se me informan las fugas en el curso normal de desarrollo, cada vez que finaliza un proceso.

Ahora que nos estamos mudando al mundo de GCC, encuentro que las herramientas de detección de fugas de memoria, muchas de las cuales son bastante sofisticadas, requieren que indique explícitamente que estoy en modo de búsqueda de fugas. Mi IDE es Xcode y he investigado algunas de las herramientas de detección de fugas / asignación (como Instruments y MallocDebug), pero reconozco que todavía no he dedicado el tiempo para comprenderlas. Sigo decepcionándome por el hecho de que en realidad tengo que especificar que estoy buscando una fuga antes de tiempo, en lugar de que me avisen automáticamente.

Estoy usando Xcode 3.2 y escucho que ahora hay una integración ingeniosa con una herramienta de análisis estático, pero una vez más no he investigado esto. Estoy buscando una idea de cuáles son mis opciones. ¿Existe un mecanismo comparable integrado en GCC y / o Xcode? ¿Existe una biblioteca o herramienta de terceros simple que realice la funcionalidad muy básica que conozco y amo? ¿O debería aspirarlo y aprender la nueva forma de hacer las cosas?

Answer 1

Debería echar un vistazo al " Detector de fugas de memoria multiplataforma ", muy similar a la técnica crtdbg.h.

Answer 2

No conozco nada "incorporado" que haga lo que usted describe, pero no parece que sea muy difícil "rodar su propia versión" de esto. Solo desea que su depuración sea nueva para registrar el puntero, el archivo y la línea en un map<void*, AllocationInfo> donde la clave es el puntero asignado y el valor ( AllocationInfo ) sería una estructura que contiene el nombre del archivo, el número de línea, etc. También debe definir un operador de eliminación personalizado que compruebe el mapa para el puntero que se está eliminando. Si se encuentra, esa entrada se elimina del mapa. Luego, al momento del cierre del proceso, usted emite los contenidos del mapa.

Encontré una página donde alguien describe su propio sistema propio que funciona así .

Answer 3

Tal vez podría usar el recolector de basura Boehm como herramienta de detección de fugas:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html

Desde el sitio:

#include "leak_detector.h"

main() {
    int *p[10];
    int i;
    /* GC_find_leak = 1; for new collector versions not     */
    /* compiled with -DFIND_LEAK.               */
    for (i = 0; i < 10; ++i) {
    p[i] = malloc(sizeof(int)+i);
    }
    for (i = 1; i < 10; ++i) {
    free(p[i]);
    }
    for (i = 0; i < 9; ++i) {
    p[i] = malloc(sizeof(int)+i);
    }
    CHECK_LEAKS();
}   

(Te avisan vía stderr)

Answer 4

También puede encontrar útil la variable de entorno MALLOC_CHECK_.

De la página man de malloc (3):

Las versiones recientes de Linux libc (posterior a 5.4.23) y glibc (2.x) incluyen una implementación de malloc () que se puede ajustar a través de variables de entorno. Cuando se establece MALLOC_CHECK_, se usa una implementación especial (menos eficiente) que está diseñada para ser tolerante frente a errores simples, como las llamadas dobles de free () con el mismo argumento, o las saturaciones de un solo byte (errores off-by-one ). Sin embargo, no todos los errores pueden protegerse y pueden producirse pérdidas de memoria. Si MALLOC_CHECK_ se establece en 0, cualquier daño detectado en el montón se ignora silenciosamente; si se establece en 1, se imprime un mensaje de diagnóstico en stderr; si se establece en 2, abort (3) se llama inmediatamente; si se establece en 3, se imprime un mensaje de diagnóstico en stderr y se cancela el programa. El uso de un valor MALLOC_CHECK_ distinto de cero puede ser útil porque, de lo contrario, podría producirse un bloqueo mucho más tarde, y la verdadera causa del problema es muy difícil de localizar.

Answer 5

Tienes una serie de opciones disponibles para ti.

Primero, y más popularmente, puede ejecutar su aplicación bajo herramientas como Valgrind . Eso debería indicar una serie de abusos de la memoria, como las lecturas y escrituras de los punteros NULL y las pérdidas de memoria. Hay una serie de herramientas disponibles en la suite de Valgrind, así que asegúrese de revisarlas.

Segundo, siempre puedes usar una biblioteca que usa el truco LD_PRELOAD . Básicamente, el truco LD_PRELOAD permite la inyección de DLL, lo que significa que se pueden crear herramientas para ayudar a rastrear el uso de la memoria dentro de su aplicación sin cambiar nada. Encontrará herramientas como dmalloc y efence que serán bastante extensas en las instalaciones de depuración que ofrecen.

Por último, los lanzamientos recientes de GCC incluyen una herramienta llamada Mudflap . Básicamente, utiliza la función de instrumentación para ajustar las llamadas alrededor de las mismas funciones de memoria que dmalloc, eence y Valgrind. El programa será notablemente más lento y se puede ajustar en tiempo de ejecución, aunque parece que tiene mucho potencial.

He usado los tres y he encontrado a Valgrind muy útil. También me ha interesado mucho usar Mudflap, aunque todavía no he podido.

Answer 6

Tuve el mismo problema cuando comenzamos a migrar a la Mac. "Ejecutar con la herramienta de rendimiento -> Fugas" fue el único que encontré y estoy menos que encantado con él ... al menos en comparación con CRTDEBUG. Entiendo que hay algunas opciones (como lo describen otros aquí), pero eventualmente, dado que somos multiplataforma, estamos usando Windows para buscar las fugas.

Ya que mencionas el analizador estático. Pasamos un tiempo tratando de resolver el problema para ponerlo en funcionamiento hasta que encontramos que solo hace C pero no C ++