valgrind - Buscar pérdida de memoria en una biblioteca compartida

Necesito saber cómo encontrar las fugas de memoria en una biblioteca compartida que se cargará en un archivo binario de publicación. Me refiero a la biblioteca compartida que construí con la opción -g pero el binario que carga la biblioteca compartida no está construido con la opción -g.valgrind - Buscar pérdida de memoria en una biblioteca compartida

Recibo el informe de fuga de la siguiente manera.

==739== at 0x4A05809: malloc (vg_replace_malloc.c:149) 
==739== by 0x84781B1: ??? 
==739== by 0x87507F5: ??? 
==739== by 0x874CF47: ??? 
==739== by 0x874E657: ??? 
==739== by 0x874F7C2: ??? 
==739== by 0x8779C0C: ???

Hágame saber cómo obtener el rastro de pila de la fuga de la biblioteca compartida?

Fuente

2012-09-27 Naga

Suponiendo que la fuga proviene realmente de su biblioteca compartida, entonces no creo que el problema sea la falta de depuración en el ejecutable principal.

Es muy probable que su problema sea que el ejecutable está descargando la biblioteca compartida llamando al dlclose antes de que finalice. Eso significa que cuando valgrind comprueba si hay fugas, toda la información de símbolos de la biblioteca se ha ido porque la biblioteca ya no está cargada.

Si puede reconstruir el ejecutable, la solución más fácil puede ser detenerlo temporalmente llamando al dlclose para que la biblioteca permanezca cargada hasta el final.

Si no puede hacer eso, entonces trate de usar LD_PRELOAD para mantener cargada la biblioteca, así:

LD_PRELOAD="/path/to/library.so" valgrind my-executable

que se espera engañar al enlazador dinámico en mantener la biblioteca cargada incluso después de que se ha cerrado .

Fuente

2012-10-30 10:02:31 TomH

Había un parche que proporcionaba una opción para desactivar la descarga de símbolos después de dlclose. El parche funciona y lo he usado muchas veces. Pero el parche estaba en la versión anterior y creo que ahora está podrido. https://bugs.kde.org/show_bug.cgi?id=79362 – k0n3ru

@TomH: Permítanme señalar que la solución alternativa "omit dlclose" puede generar muchos falsos positivos. Si hay objetos en la pila que destruyen elementos, que estaban en el montón, entonces estos se mostraron en la salida como fugas, porque dcloto habría hecho la destrucción en primer lugar. – newhouse

Y el segundo no funciona tan bien, si valgrind es de 64 bits, pero depura 32 – newhouse

Como sugiere la respuesta anterior, esto se debe a que ha cerrado sus bibliotecas antes de que el programa finalice y, por lo tanto, la información del símbolo no está disponible para valgrind.

El uso de LD_PRELOAD no funcionó para mí; Ahora tengo dos construcciones; uno que explícitamente no llama a dlclose(); en esta compilación, valgrind informa correctamente la información del número de línea como se esperaría con la vinculación dinámica.

Fuente

2013-02-18 06:57:31 Doug

valgrind - Buscar pérdida de memoria en una biblioteca compartida

Respuesta

Cuestiones relacionadas