como detectar memory leaks

[efegea]

Pues eso, tengo un memory leak como una casa de grande, a los pocos segundos ya está consumiendo el programa más de 100 megas de ram. Yo libero todas las surfaces que uso, asi que no se donde está el problema.

¿Hay alguna forma de detectar los memory leaks?

[miq01]

Hay programas que se encargan de hacer un análisis en tiempo de ejecución y luego te muestran estadísticas (las funciones más llamadas, las que usan más CPU, más memoria, etc., y posibles "memory leaks"). No conozco ninguno gratuito, pero no me extrañaría que hubiera alguno. ¿Tu tiras de Linux, no? Lo digo porque a malas puedes probar el Rational Purify (http://www-306.ibm.com/software/awdtools/purify/unix/). El problema es que es de pago y seguro que vale un pastón, pero siempre puedes buscarlo donde ya sabemos.

Que pootas son los memory leaks... :)

< - >
Por cierto, no lo he probado pero quizá buscando "finding memory leaks" en Google encuentras algo...

[efegea]

He encontrado varios programas gratuitos pero ninguno me funciona. Y el que se supone que es el mejor, el valgrind, se me queda pillado justo antes de comenzar el primer nivel, que es donde está el memory leak.

Al final no me va a quedar otra opcion que analizar todo el código fuente en modo busca y captura

[kraff2]

No lo he usado, pero he visto en varios hilos de KDE el uso de Valgrind y al parecer es bastante útil. Seguramente estará en los repositorios de tu distro (por lo menos en ubuntu si está). Si usas el kdevelop viene integrado en una de las pestañas inferiores

Página oficial: http://valgrind.org/
Howto: http://www.tldp.org/HOWTO/Valgrind-HOWTO/index.html


Con un "apt-cache search memory leak" salen algunas entradas que también pueden ser útiles:

ccmalloc - A memory profiler/debugger
leaktracer - Simple and efficient memory-leak tracer for C++ programs
kmtrace - a KDE memory leak tracer

Como último recurso puedes echar mano de algún debugger o frontend gráfico estilo ddd y hacer "cansinas" trazas.

Suerte con esa "amnesia" ;)

< - >
Vaya no había leído tu último post, olvida lo del valgrind ;)

[Uncanny]

También puedes hacer uso de mtrace, de la función y de la utilidad me refiero (el Kmtrace que habla kraff2 es un GUI para KDE de esta utilidad), que es de GNU GLIBC, tu toolchain la tiene que traer, hay algún que otro programa más pero este es de los más sencillos de usar (aunque sea en la linea de comandos), lo único que require esta utilidad es que en tu código añadas la función mtrace() (tal cual, no hay que pasarle ningún valor ni guardarlo en ninguna variable) uses la función mtrace() (añadiendo la cabecera mcheck.h a tu programa) y luego trazar un log de tu programa con la utilidad mtrace.

Más info del uso de mtrace en su man y en esta web:

http://www.devx.com/tips/Tip/20915

Quizás te interese leer esta otra (centrada en este tipo de programas para sistemas embebidos como la GP2X):

http://www.linuxjournal.com/article/6059

Por otro lado están los profilers como gprof (parte de GNU Binutils) que es facil de usar y otros como Valgrind, solo que este no tiene versión para ARM Linux, así que te vale para comprobar un programa compilado para x86 en Linux, pero no para usarlo con la GP2X (cosa que si se puede hacer con gprof).

[efegea]

uncanny, tengo un problema con mtrace y es que tengo que añadir un include, que según "man mtrace" es "macheck.h" pero no está en mi sistema. Lo he buscado con find y nada. Es muy raro porque se supone que es de la glibc :confused:

Acabo de ver en en enlace que me has dado que no es "macheck.h" sino "mcheck.h"...¡la pagina del manual está mal! :S

< - >
De todas formas ya tengo aislado el leak, está en el método CBadGuys::draw(), pero no veo nada que pueda ser, tendré que seguir aislando hasta que dé con él. De todas formas voy a probar el mtrace que seguro que da informacion interesante.

< - >
La salida de mtrace no me vale :( me salen numeros en hexadecimal en lugar de especificarme la línea del memory leak. Estoy siguiendo las instrucciones del enlace pero nada >_<

< - >
Bueno, detectado y eliminado. Era una función que devolvía una SDL_Surface, no tenía forma de liberarlaHe tenido que cambiar de estrategia y convertirla en una función que pinta directamente en pantalla.

Por cierto, ¿hay alguna forma, en linux, de saber exactamente cuánta memoria está consumiendo el proceso? Sé que 'ps' y 'top' te dan información de la memoria pero no sé que significa cada valor.

< - >
Comparando la salida de 'free' antes y mientras se está ejecutando el programa, la diferencia de memoria es de 15 megas.

Claro que supongo que ahí iran incluidas las librerías: sdl, sdl_image, sdl_mixer, etc..

[Uncanny]

La salida de mtrace no me vale :( me salen numeros en hexadecimal en lugar de especificarme la línea del memory leak. Estoy siguiendo las instrucciones del enlace pero nada >_<Yo he usado mtrace con programas en C, pero no en C++, aunque creía que no habría problemas...

Las otras opciones que conozco es MemWatch (bastante bueno y da una información detallada), pero también es para usarlo con C (solo tiene soporte parcial y desactivado por defecto para C++), para C++ se que LeakTrace es adecuada, verificando la gestión de memoria cuando usas los operadores new y delete (lo que no se es su efectividad cuando haces uso de las funciones de librerías escrita en C como SDL) y por último una utilidad y librería que vi hace poco pero que aun no he probado llamada DUMA (http://duma.sourceforge.net/).
Por cierto, ¿hay alguna forma, en linux, de saber exactamente cuánta memoria está consumiendo el proceso? Sé que 'ps' y 'top' te dan información de la memoria pero no sé que significa cada valor.Con top puedes ver el porcentaje de memoria consumido respecto a la memoria total que tienes mientras está en ejecución el proceso, lo mejor es tener una consola abierta con viendo lo que consume el proceso del programa mientras lo estás ejecutando.

[animanegra]

Buenas:

No se si seguiras con ese problema. Puede que el valgrind se te quede pillado porque no puede volcar toda la informacion. A veces simplemente puedes enviarle un SIGSEGV y te vuelca la información de donde está. Puedes también (Supongo que lo habras hecho) bajarle para que no te depure tanto el nivel de leacks y el numero de funciones que guarda en pila.
--leak-resolution=low y --num-callers= ponle un numero bajo. A ver si asi no se te keda pillao. :S

Si no lo que puedes hacer es poner un printf con linea "%s %d %p",__FUNCTION__,__LINE__,puntero en cada direccion de memoria con malloc y en cada linea con free. Yo me hice un script que te recogia la informacion de ese archivo y te decía donde tenias el error, si quieres te lo paso es un bash muy simplote, va apilando los malloc y te va quitando los frees. Esta preparado para detectar dos frees de una misma direccion, pero no cuesta nada cambiarlo para que te visualice la pila de los mallocs que tienes sin librerar.

Aupa

[una-i]

A mi lo que mejor me ha funcionado de siempre es instrumentalizar el codigo y no llamar nunca ni a malloc ni a free.

Hay una libreria que hace eso y detecta tanto memory leaks como escrituras fuera de rango... yo es posible que hab auna un poco mas sencillita al estilo de mi profiller, y la cuelge por aqui algún dia.

El código que te decia es este, yo no lo he usado porque siempre he ehcho el mio, peor este lo ha usado mucha gente y no se han quejado...

http://www.fluidstudios.com/pub/FluidStudios/MemoryManagers/Fluid_Studios_Memory_Manager.zip

P.D: Leete bien los comentarios del .h y el .cpp para que lo incluyas en el código correctamente o va a darte problemas.



Unai.

[firecode]

Para que el valgrind funcione bien lo tienes que compilar con la informacion de debug. Valgrind vuelve el codigo MUY lento, por lo que tendras que tener algo de paciencia.

Yo lo he utilizado en varios proyectos y me ha resultado muy util.