Discussion :

[Vinkkk]

Bonjour à tous,
mon programme crash en ce moment du coup j'essaie de le debugger avec gdb mais j'avoue ne pas maîtriser cet outil. J'ai cherché sur internet des cours mais le problème c'est que bien souvent il l'utilise avec des programmes avec seulement un main. J'ai donc plusieurs question à poser par rapport à l'utilisation de gdb :

- Comment ignorer les appel de librairie (SDL dans mon cas) ?
- Comment connaître la ligne qui nous intéresse pour placer un breakpoint ?
- Quel debbuger utilisez-vous ?

En vous remerciant !

[foetus]

Comment ignorer les appel de librairie (SDL dans mon cas) ?

En commentant la ligne

Comment connaître la ligne qui nous intéresse pour placer un breakpoint ?

À l'ancienne en pourrissant son code de traces afin d'avoir [+ ou -] le chemin d'exécution et trouver l'endroit où le programme part sur Mars sans retour

[jo_link_noir]

Ma principale utilisation de gdb se résume à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
> r
Segfault... :'(
> bt
> ctrl+D

(J'ai un script qui le fait avec quelques options)

r = run
bt = backtrace

Et c'est seulement après avoir la pile d'appel que je sais quoi regarder et où mettre d’éventuel breakpoint (b fonction ou b fichier:numligne (il y a l'auto-complétion)). La plupart du temps je ne vais pas plus loin, mais j'affiche éventuellement les valeurs (p expression) ou je me déplace sur une frame de la trace (f num) pour voir les états dans les fonctions et list pour afficher le code autour de la ligne courante.

Après, je préfère le rendu de lldb, mais sinon il y a TUI (gdb -tui ou ctrl+x,ctrl+a) pour une interface plus sympathique. Voir d'autre truc comme gdb-dasboard ou des programmes dédiés.

[Vinkkk]

Après, je préfère le rendu de lldb, mais sinon il y a TUI (gdb -tui ou ctrl+x,ctrl+a) pour une interface plus sympathique. Voir d'autre truc comme gdb-dasboard ou des programmes dédiés.

J'ai vu l'interface de gdb, ça à l'ai intéressant mais je ne sais pas si elle disponible sur MSYS, faut que je me renseigne

À l'ancienne en pourrissant son code de traces afin d'avoir [+ ou -] le chemin d'exécution et trouver l'endroit où le programme part sur Mars sans retour

c'est-à-dire ? en mettant des printf() un peu partout ? Parce que moi pour l'instant je n'ai pas trouvé de technique qui marche mieux que ça !

[foetus]

c'est-à-dire ? en mettant des printf() un peu partout ? Parce que moi pour l'instant je n'ai pas trouvé de technique qui marche mieux que ça !

Oui mais ce n'est pas non plus la solution miracle :

• Lorsque tu as des boucles, tu peux avoir plusieurs fois la même trace qui peuvent masquer celle(s) intéressante(s)
• L'affichage dans la ligne de commandes est souvent assez lent, et dans un contexte multithreadé, en ralentissant 1 fil d'exécution (thread) tu peux avoir des race conditions