lista áreas de memoria "frías"

Estoy tratando de encontrar un error muy evasivo en un software de servidor que parece una pérdida de memoria, pero memcheck no ayudó en absoluto. Mi suposición es que la memoria que ha sido instanciada y nunca eliminada no se ha filtrado, por lo que hay una referencia a ella, pero ahora es inútil para el programa y debe eliminarse. ¿Existe alguna herramienta que pueda contar los accesos, no las referencias, en la memoria, y así dar una evaluación del uso efectivo de los objetos en el montón?lista áreas de memoria "frías"

Fuente

2011-12-26 Lorenzo Pistone

Valgrind debe informar cosas que nunca se han liberado como "todavía alcanzables"; ver http://valgrind.org/docs/manual/faq.html#faq.deflost. –

@oli: es posible que desee publicar su comentario como respuesta para que pueda marcarse como aceptado. Parece que es la respuesta correcta para mí, de todos modos. – casualcoder

Ya he ejecutado memcheck con este programa y no mostró nada. –

que terminó con la implementación de mi propia herramienta. Mi enfoque era un poco diferente de lo que pretendía: escribí un malloc hooking library. Enloca malloc, realloc y free, y mantiene una lista de bloques de memoria malloc vivos. Cada vez que envíe un SIGUSR1 a su aplicación, volcará su información en un archivo y lo evaluará como una expresión Mathematica. El cuaderno de Mathematica finalmente proporciona algunos gráficos muy útiles: instancias de puntaje superior by call stack, y una descripción completa de calls to malloc. Con estas herramientas, tuve que pasar el mouse sobre el punto verde más grueso y más distante del centro del segundo gráfico, y, voilà, tengo la dirección que ejemplifica una gran cantidad de memoria no filtrada pero inútil.

P.S. Las llamadas circulares que se pueden ver en el segundo gráfico son definitivamente un error en el backtrace de libc().

Fuente

2011-12-28 09:35:09

Me sorprende que valgrind no haya hecho lo que usted quería, no ha habido un escape de memoria que valgrind no haya recogido para mí. – dreamlax

Este error es extremadamente elusivo por otra razón: otro tipo ha encontrado una manera de desencadenarlo de forma confiable en su compilación, pero ese método no funciona para el mío (la misma fuente nueva y sin tocar, por supuesto). Entonces, Memcheck no encontró nada obviamente para mí, pero este tipo me dijo que sí ejecutó Memcheck y no devolvió nada, y no tengo motivos para pensar que haya hecho algo mal. Los datos que se muestran en los gráficos provienen también de su construcción. Sospecho que de alguna manera está relacionado con la bitness, construye ejecutables de 32 bits para poder compartir la misma compilación en cualquier servidor, mientras que construí solo ejecutables de 64 bits. –

Probablemente esta herramienta (Visual Leak Detector) te ayude. Es gratis.

http://vld.codeplex.com/

Fuente

2011-12-27 05:55:08 DaddyM

parece un detector de fugas normal, como he dicho, mi problema es que la memoria extra en uso no se ha filtrado técnicamente, porque todavía hay referencias a ella. Además, estoy trabajando con gcc. –

Respuesta

Cuestiones relacionadas