Pour faire suite au journal Un debugger est-il indispensable ?, il serait intéressant de connaître le ou les debuggeurs utilisés par les visiteurs de LinuxFr.org :
-
gdb :
519(25.7 %)
-
valgrind :
100(5.0 %)
-
Celui de mon EDI (Eclipse, Netbeans, Qtcreator, VisualStudio, etc.) :
404(20.0 %)
-
Nemiver :
11(0.5 %)
-
printf roxor :
371(18.4 %)
-
Autre (utilisez les commentaires) :
34(1.7 %)
-
R2-D2 :
233(11.5 %)
-
Aucun, pas besoin... :
348(17.2 %)
Total : 2020 votes
# Choix multiples
Posté par Cyril F (site web personnel) . Évalué à 10.
GDB et Valgrind …
http://la-rache.com
[^] # Re: Choix multiples
Posté par zul (site web personnel) . Évalué à 7.
Gdb, valgrind ou printf (ou système de logging approprié), tout dépend du système à débugger!
[^] # Re: Choix multiples
Posté par Mathias Bavay (site web personnel) . Évalué à 4.
Pareil: printf pour les processus longs et un peu laborieux à débugger avec un débuggeur normal (du style "la millionième boucle se comporte mal quand la date est est sur une année bisextile etc etc"), gdb pour le pas à pas (via kdbg) ou les core dumps et valgrind, Cppcheck, etc pour essayer d'aller plus en profondeur.
Mathias
[^] # Re: Choix multiples
Posté par Zylabon . Évalué à 7.
en gdb ça se dit :
break ligne if (iter == 100000000 && bisextile(année(date)))
Please do not feed the trolls
[^] # Re: Choix multiples
Posté par wysman . Évalué à 10.
+1, on ne cherche pas la même chose avec GDB et Valgrind
[^] # Re: Choix multiples
Posté par yabb85 . Évalué à 2.
+1 je ne fais pas la même chose avec les 2
[^] # Re: Choix multiples
Posté par grim7reaper . Évalué à 1.
D’ailleurs Valgrind en lui-même ce n’est pas un débogueur mais un framework d'instrumentation binaire qui permet de créer des outils d’analyses dynamiques.
Après, certains de ces outils d’analyses sont effectivement utiles pour du débogage (mais ce ne sont toujours pas des débogueurs !), d’autres non (plutôt orienté profilage).
[^] # Re: Choix multiples
Posté par Batchyx . Évalué à -1.
Le fait que memcheck puisse lancer gdb lorsqu'il détecte un problème le classe dans la catégorie des front end de débuggeurs, au moins.
[^] # Re: Choix multiples
Posté par grim7reaper . Évalué à 2.
Non.
Un front-end de débugger ça ne se contente pas de lancer le débugger uniquement, et après tu joues directement avec le débugger lui-même sans rien entre toi et lui.
À ce compte là, je fais un script shell qui attache gdb à un process et j’appelle ça un front-end…
[^] # Re: Choix multiples
Posté par Batchyx . Évalué à 1.
Si ton script shell peut trouver des bugs avant d'appeler le débuggeur, je vois pas ou est le problème.
[^] # Re: Choix multiples
Posté par grim7reaper . Évalué à 3.
Bon écoute, je crois qu’il faut que tu revoies la définition d’un front-end de débogueur parce que sinon on est pas sortie du sable -___-"
Un front-end de débogueur ne détecte pas de bugs, c’est pas son taff (c’est le taff du débogueur en back-end + programmeur).
Un front-end de débogueur ne se contente pas de lancer le débogueur.
Un front-end de débogueur ça propose une interface, graphique (genre Eclipse) ou pas (genre M-x gdb-many-windows sous Emacs), qui permet d’interagir avec le débogueur et d’afficher diverses infos (par exemple : pile d’appel, contenue des variables et registres, liste des breakpoints, position dans le code source, listing asm, …)
Maintenant, il va falloir que tu m’expliques en quoi memcheck est un front-end de gdb, parce que là je ne vois toujours pas (où alors on a pas la dernière version de memcheck)…
# mon code est bug free
Posté par djibb (site web personnel) . Évalué à 10. Dernière modification le 20 mai 2013 à 11:45.
Et je ne comprends pas comment on peut faire un code avec des bugs
[^] # Re: mon code est bug free
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
C'est comme aire une phrase avec une faute (cf "Dernière modification : le 20/05/13 à 11:45 ") :).
[^] # Re: mon code est bug free
Posté par DerekSagan . Évalué à 4.
Je crois que ton clavier s'est oqué
[^] # Re: mon code est bug free
Posté par Professeur Méphisto . Évalué à 4.
Comment un clavier peut-il se moquer ?
[^] # Re: mon code est bug free
Posté par ariasuni . Évalué à 1.
Moi mon clavier ne se moque pas, par contre des fois il se blo
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: mon code est bug free
Posté par DerekSagan . Évalué à 2.
Tu veux dire que tu utilises en fait un clavier bé
[^] # Re: mon code est bug free
Posté par ariasuni . Évalué à 1.
C’est tout à
Écrit en Bépo selon l’orthographe de 1990
# LLDB
Posté par Valerian (site web personnel) . Évalué à 2.
C'est un choix cornélien quand c'est à la fois celui de mon EDI et un autre. Et en l'occurrence, il s'agit de LLDB.
Est-il si peu utilisé qu'il ne s'agit pas d'un choix distinct dans le sondage ?
# OCaml
Posté par Michaël (site web personnel) . Évalué à 8.
À cette heure, un seul programmeur OCaml a répondu au sondage! :-)
# ipdb
Posté par woprandi . Évalué à 3.
voilà
[^] # Re: ipdb
Posté par Mali (site web personnel) . Évalué à 1.
cgdb
[^] # Re: ipdb
Posté par Emmanuel C . Évalué à 1.
pdb tout court pour ma part
# A reformuler ;)
Posté par Ix4r . Évalué à 8. Dernière modification le 20 mai 2013 à 16:52.
Quelques remarques:
De toute façon ma réponse est 42 ;)
# strace et ltrace
Posté par goeb . Évalué à 7.
Il existe aussi strace et ltrace, qui affichent les appels systèmes et les appels de fonctions entre bibliothèques. Ça permet de débugguer les problèmes de PATH, de working directory, de socket réseau, de configuration, de variables d'environnement, etc.
[^] # Re: DTrace
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Et DTrace.
[^] # Re: DTrace
Posté par Krunch (site web personnel) . Évalué à 4.
Et SystemTap.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# il y a des gens ici qui font des bugs ?
Posté par DerekSagan . Évalué à 6.
J'ai toujours cru que les debugger était des projets étudiants encore détachés de la réalité du monde du travail et qu'ils n'étaient jamais utilisés par les vrais programmeurs.
Quelle déception!
# gdb
Posté par Old Geek . Évalué à 4.
gdb avec les surcouches ddd et xxgdb
# Celui qui est adapté
Posté par fearan . Évalué à 4. Dernière modification le 21 mai 2013 à 11:50.
Valgrind pour les bug chelou aléatoire ou les fuites mémoires
printf pour un truc rapide
gdb pour les truc un poil plus pointus ou si le nombre de printf devient trop important ;)
Ah et j'oubliais,
le collègue lorsque ça vient d'une partie à lui ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Un esclave
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 8.
C'est moins économique, mais c'est plus humain !
# Aucun car pas adapté à mon code
Posté par vlamy (site web personnel) . Évalué à 3.
Mon code est trop complexe pour un debugger :)
Plus sérieusement je fais essentiellement de l'implémentation de protocole, donc du code distribué et les bugs se situent, dans 90% des cas, dans l'état partagé du système (variables désynchronisées, deadlock distribué,…etc). Et là le debugger est généralement inutile, du coup je suis habitué à utiliser des traces dans les logs, et j'utilise un outil maison pour fusionner les logs de plusieurs machines. Je vous passe les problématiques de causalité, ordre total,…etc
C'était juste pour donner un exemple légitime de cas où le debugger n'est pas à la hauteur.
[^] # Re: Aucun car pas adapté à mon code
Posté par xcomcmdr . Évalué à 1.
Qu'est-ce ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Aucun car pas adapté à mon code
Posté par grim7reaper . Évalué à 2.
Tu n’as jamais étudié les systèmes distribués (ne serait-ce qu’une intro) ?
C’est un des premiers trucs que l’on voit.
Ce topic (première réponse + commentaires) de stackoverflow explique la différence ordre total/ordre partiel, si jamais ça peut t’éclairer un peu :)
[^] # Re: Aucun car pas adapté à mon code
Posté par xcomcmdr . Évalué à 2.
Nope, rien de la sorte. Ou alors de très loin.
Merci beaucoup pour le lien, c'est tout simple en fait. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Aucun car pas adapté à mon code
Posté par vlamy (site web personnel) . Évalué à 3.
Par abus de langage on parle aussi d'évènements atomiques. Par exemple, une diffusion de message atomique est une diffusion totalement ordonnée, c.à.d. grossièrement un broadcast pour lequel tous les destinataires traitent les messages dans le même ordre. C'est beaucoup utilisé pour la réplication de base de données, par exemple, pour assurer que tous les répliquas sont dans le même état.
# Perl powered
Posté par reno . Évalué à 2.
Celui intégré dans Perl, j'avoue ne pas savoir lequel c'est..
[^] # Re: Perl powered
Posté par tyoup . Évalué à 4.
/dev/random ?
[^] # Re: Perl powered
Posté par anaseto . Évalué à 1.
Ce que j'aime bien, c'est la première phrase de la page man « perldebug » :
# printf est une valeur sûre
Posté par NanoTech . Évalué à 1.
Même si j'admire la qualité de GDB, je localise plus rapidement les bogues avec fprintf(stderr,…)+du code pour aller dans l'état bogué qu'avec GDB parce que je peux rapidement faire un cycle modif/compile/exec, alors que je perds du temps pour retourner à l'état bogué sous GDB.
Par contre, je trouve GDB très commode pour faire la BackTrace (BT) des appels lors d'une exception (SIGSEGV).
# Firebug
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Moi j'utilise Firebug. Bah oui, les applis web ça se debugge aussi :)
Mais le plus souvent, j'utilise le printf du web : console.log() (ou dump() pour le JS des extensions Fx/Applis XulRunner)
Il fut un temps également où j'utilisais Venkman (quand j'étais jeune).
Sinon gdb j'ai jamais pu pifré, donc c'est toujours via un IDE. Ou alors printf. J'adore printf.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.