En GDB, ¿cómo saber quién malloc'ed una dirección en el montón?

Tengo un puntero en GDB, ¿cómo puedo averiguar dónde se asignó por primera vez en el montón?En GDB, ¿cómo saber quién malloc'ed una dirección en el montón?

En WinDBG, esto se puede hacer por !heap -p -a <0x12345678> después de encender gflags /i <*exe> +ust

Desde Valgrind me puede decir donde se asigna la memoria (cuando detecta algunas fugas), supongo que esto también es posible?

(no se trata de punto de observación. Esto se da la situación en la que rompo aleatoriamente en el En el BGF, la aplicación, mirar a un puntero y quieren saber "que creó este pedazo de la memoria"?)

el uso de depuración inversa en GDB es una forma novedosa y probablemente la correcta manera de resolver este problema. Encontré algún problema con ese enfoque con GDB 7.1, la última versión estable. La depuración inversa es una característica bastante nueva en GDB, así que tuve que echar un vistazo a HEAD (7.2) para solucionarlo.

Probablemente dice algo sobre la madurez del enfoque BGF pero creo que definitivamente se debe utilizar cuando es más maduro. (Característica impresionante!)

Fuente

2010-07-26 kizzx2

Valgrind secuestra llamadas de gestión de memoria, que es como funcionan las fichas del montón. No hay ninguna facilidad en GDB para decirle dónde se devolvió la dirección dada por malloc(3). Sugiero mirar en mtrace y glibc allocation debugging.

Fuente

2010-07-26 14:14:08

Gracias! Tanto su enfoque como ks1322 parecen válidos. Es útil conocer la depuración de la asignación mtrace y glib. Por otro lado, creo que el enfoque de ks1332 es más inteligente y probablemente esté más cerca de GDB (por lo tanto, el título de la pregunta). Voy a experimentar con ambos y ver cuál es mejor en la práctica antes de elegir una respuesta correcta. – kizzx2

Tal vez reverse debugging ayudará aquí. Intente establecer el punto de observación en la dirección de la memoria y reverse-continue hasta que se escriba la memoria.

(gdb) watch *0x12345678 
(gdb) reverse-continue

Fuente

2010-07-26 18:01:44 ks1322

¡Gracias! Tanto su enfoque como Nikolai parecen válidos. Su enfoque es más inteligente y probablemente esté más cerca de GDB (por lo tanto, el título de la pregunta). Por otro lado, es útil conocer la depuración de la asignación mtrace y glib. Voy a experimentar con ambos y ver cuál es mejor en la práctica antes de elegir una respuesta correcta. – kizzx2

Sí, esto es divertido, pero no creo que sea práctico más que para programas muy pequeños (nunca importa el multihilo). –

@Nikolai: parece ser cierto. Si bien la depuración inversa es realmente emocionante desde el punto de vista técnico, probablemente no sea lo suficientemente madura en muchos casos. Un inconveniente es que 'record' * no * se ejecutará en un programa Hello World, porque se niega a grabar cualquier IO (TTY, sistema de archivos, etc.). Solo eso hace que no sea práctico usarlo en cualquier situación de la vida real. No estoy seguro de si ese es el comportamiento previsto. – kizzx2

record DOES se ejecuta en un programa Hello World. ¡Heck uso el registro para depurar el gdb mismo!

Fuente

2010-07-28 18:20:26

¡Gracias por recordarnos! Obviamente fui ignorante cuando lo intenté, decía "operación sin soporte o algo así". Creo que podría estar relacionado con problemas de 32 bits a 64 bits. Lo intenté de nuevo en un Ubuntu de 32 bits y funcionó a las mil maravillas. ¿Alguna orientación sobre por qué podría no funcionar en Arch x86_64? (Sospecho que podría estar relacionado con la versión de 64 bits de glibc o algo, no sé: P) – kizzx2

grabación/repetición a veces escupe algunas advertencias, pero eso no significa necesariamente que no esté funcionando. También debería funcionar para x86_64, pero el soporte de i386 es más maduro. –

Analicé el problema.Este problema en particular se debe a que mi libc fue compilada para contener algunas instrucciones de MMX que GDB 7.1 no soportaba. Revisé HEAD (7.2 al momento de escribir) y funcionó. – kizzx2

En GDB, ¿cómo saber quién malloc'ed una dirección en el montón?

Respuesta

Cuestiones relacionadas