Dans GDB, comment savoir qui a placé une adresse sur le tas?

J'ai un pointeur dans GDB, comment puis-je savoir où il a été alloué pour la première fois sur le tas?Dans GDB, comment savoir qui a placé une adresse sur le tas?

En WinDBG, cela peut être fait par !heap -p -a <0x12345678> après la mise gflags /i <*exe> +ust

Depuis Valgrind peut me dire où la mémoire est allouée (lorsqu'il détecte des fuites), je suppose que cela est possible?

(Ce n'est pas sur point d'observation. Ceci est donné la situation dans laquelle je me casse au hasard dans le gdb, l'application, regardez un pointeur et que vous voulez savoir « qui a créé ce morceau de mémoire »?)

L'utilisation de débogage inverse dans GDB est un moyen très nouveau et probablement le corriger façon de résoudre ce problème. J'ai rencontré un problème avec cette approche avec GDB 7.1 - la dernière version stable. Le débogage inversé est une fonctionnalité plutôt nouvelle dans GDB, j'ai donc dû vérifier HEAD (7.2) pour le réparer.

Il est probablement dit quelque chose sur la maturité de l'approche GDB mais je pense qu'il devrait certainement être utilisé quand il est plus mature. (Fonctionnalité géniale!)

Source

2010-07-26 kizzx2

Valgrind détourne les appels de gestion de la mémoire, c'est comme ça que fonctionnent les vérificateurs de tas. GDB ne peut pas vous indiquer où l'adresse indiquée a été renvoyée par malloc(3). Je suggère de regarder dans mtrace et glibc allocation debugging.

Source

2010-07-26 14:14:08

Merci! Votre approche et ks1322 semblent valables. Il est intéressant de connaître le débogage d'allocation mtrace et glib. D'un autre côté, je pense que l'approche de ks1332 est plus intelligente et probablement plus proche de GDB (donc le titre de la question). Je vais expérimenter avec les deux et voir lequel est le mieux en pratique avant de choisir une bonne réponse. – kizzx2

Peut-être reverse debugging aidera ici. Essayez de définir le point de contrôle sur l'adresse mémoire et inverser-continuer jusqu'à ce que la mémoire soit écrite.

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

Source

2010-07-26 18:01:44 ks1322

Merci! Votre approche et celle de Nikolai semblent toutes deux valables. Votre approche est plus intelligente et probablement plus proche de GDB (donc le titre de la question). D'un autre côté, il est intéressant de connaître le débogage de l'allocation mtrace et glib. Je vais expérimenter avec les deux et voir lequel est le mieux en pratique avant de choisir une bonne réponse. – kizzx2

Oui, c'est amusant, mais je ne pense pas que ce soit pratique autrement que pour les très petits programmes (même pas le multithreading). –

@Nikolai: il semble être vrai. Alors que le reverse-debug est vraiment excitant du point de vue technique, il n'est probablement pas assez mature dans de nombreux cas. Un showstopper est que 'record' il ne sera * pas * exécuté dans un programme Hello World, car il refuse d'enregistrer tout IO (TTY, système de fichiers, etc.). Cela seul le rend peu pratique à utiliser dans n'importe quelle situation de la vie réelle. Je ne suis pas sûr si c'est le comportement voulu. – kizzx2

enregistrement DOES exécuté sur un programme Hello World. Heck J'utilise record pour déboguer gdb lui-même!

Source

2010-07-28 18:20:26

Merci de nous avoir rappelé! J'étais évidemment ignorant quand j'ai essayé - il a dit "opération non soutenue ou quelque chose." Je pense qu'il pourrait être lié à des problèmes de 32 bits 64 bits. J'ai encore essayé à un Ubuntu purement 32 bits et cela a fonctionné comme un charme! Des conseils sur pourquoi cela ne fonctionnerait pas sur Arch x86_64? (Je soupçonne qu'il pourrait être lié à la version 64 bits de la glibc ou quelque chose, je ne sais pas: P) – kizzx2

enregistrement/rejouer crache parfois quelques avertissements, mais cela ne signifie pas nécessairement que cela ne fonctionne pas. Cela devrait aussi fonctionner pour x86_64, mais le support de i386 est plus mature. –

J'ai examiné le problème.Ce problème particulier était dû au fait que ma libc était compilée pour contenir des instructions MMX que GDB 7.1 ne supportait pas. J'ai vérifié HEAD (7.2 au moment de l'écriture) et cela a fonctionné. – kizzx2

Dans GDB, comment savoir qui a placé une adresse sur le tas?

Répondre

Questions connexes