Sondage Quel débugger utilisez vous ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
6
20
mai
2013

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

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Choix multiples

    Posté par  (site web personnel) . Évalué à 10.

    GDB et Valgrind …

    http://la-rache.com

    • [^] # Re: Choix multiples

      Posté par  (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  (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  . É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  . Évalué à 10.

      +1, on ne cherche pas la même chose avec GDB et Valgrind

    • [^] # Re: Choix multiples

      Posté par  . Évalué à 2.

      +1 je ne fais pas la même chose avec les 2

      • [^] # Re: Choix multiples

        Posté par  . É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  . É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  . É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  . É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  . É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  (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

  • # LLDB

    Posté par  (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  (site web personnel) . Évalué à 8.

    À cette heure, un seul programmeur OCaml a répondu au sondage! :-)

  • # ipdb

    Posté par  . Évalué à 3.

    voilà

  • # A reformuler ;)

    Posté par  . Évalué à 8. Dernière modification le 20 mai 2013 à 16:52.

    Quelques remarques:

    • valgrind n'est pas un debugger
    • les IDE offrent une UI sur un debugger utilise en backend
    • Nemiver == frontend pour gdb (donc comparable a un IDE ?)
    • manque: idb (Intel debugger), jdb, chronon, TimeMachine…

    De toute façon ma réponse est 42 ;)

  • # strace et ltrace

    Posté par  . É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.

  • # il y a des gens ici qui font des bugs ?

    Posté par  . É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  . Évalué à 4.

    gdb avec les surcouches ddd et xxgdb

  • # Celui qui est adapté

    Posté par  . É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  (site web personnel, Mastodon) . Évalué à 8.

    C'est moins économique, mais c'est plus humain !

  • # Aucun car pas adapté à mon code

    Posté par  (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  . Évalué à 1.

      ordre total

      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  . É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  . É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  (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  . Évalué à 2.

    Celui intégré dans Perl, j'avoue ne pas savoir lequel c'est..

  • # printf est une valeur sûre

    Posté par  . É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  (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.