Journal Sondage : Debugger Or Not Debugger ?

Posté par  .
Étiquettes : aucune
0
9
oct.
2004
Attention, ce n'est pas un appel au troll des cavernes !

Je suis en train de me poser des questions existentielles (éh oui, à partir d'un certain âge ...). Il fut un temps où j'utilisais pas mal - voire beaucoup - le debugger intégré de l'EDI (en environnement Microsoft ou Linux). Puis, commença le déclin ... Et vint le moment où je n'utilisât plus du tout le debugger.

C'est grâââve, Docteur ?



-- si-vous-avez-envie-de-troller ON --

J'aime :
unsigned int Classe::GetValeur (bool b);
Je n'aime pas :
HRESULT FPCScheduledContentDownloadConfig::get_FetchUrlFlagNoArrayRoute(VARIANT_BOOL *p);

J'aime :
if (condition)
{
}
Je n'aime pas :
if( condition ){
}

etc... :-)

-- si-vous-avez-envie-de-troller OFF --
  • # Difficile de répondre...

    Posté par  (Mastodon) . Évalué à 10.

    ... tu ne nous as pas dit ce qui a provoqué ton arrêt d'utilisation du débugger.

    - Si tu n'en as pas besoin car ton code ne plante jamais, c'est plutôt une bonne chose, et donc ce n'est pas grave. Mais le risque, c'est qu'une agence secrête du gouvernement te kidnappe et fasse des expériences sur toi.

    - Si tu utilises des printf (ou assimilé) à la place, dis toi que Linus fait pareil. Donc c'est grave.

    - Si tu as arrêté la programmation, par contre, tout va bien, et tout ne peut que s'arranger. Sauf si tu as arrêté la programmation dans l'espoir de te construire une vie sociale, je ne peux que désapprouver ce genre d'éthique.
    • [^] # Re: Difficile de répondre...

      Posté par  . Évalué à 2.

      ... tu ne nous as pas dit ce qui a provoqué ton arrêt d'utilisation du débugger.

      Je ne sais pas vraiment ... J'ai une petite idée ... Peut-être parce que je commençais à faire pas mal de dll et de so ...

      - Si tu n'en as pas besoin car ton code ne plante jamais, c'est plutôt une bonne chose, et donc ce n'est pas grave. Mais le risque, c'est qu'une agence secrête du gouvernement te kidnappe et fasse des expériences sur toi.

      Si si, je produits toujours des bugs et mon code plante comme les autres (je pense), donc c'est bien parce que je ne risque pas qu'une agence secrête du gouvernement me kidnappe et me fasse des expériences dessus.

      - Si tu utilises des printf (ou assimilé) à la place, dis toi que Linus fait pareil. Donc c'est grave.

      Effectivement, j'utilise un sortie quelconque pour informer la populace de l'imminence de la bourde ... C'est VRAIMENT grave ???

      - Si tu as arrêté la programmation, par contre, tout va bien, et tout ne peut que s'arranger. Sauf si tu as arrêté la programmation dans l'espoir de te construire une vie sociale, je ne peux que désapprouver ce genre d'éthique.

      Je programme toujours ... et je suis même payé pour ...
      • [^] # Re: Difficile de répondre...

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

        >Je ne sais pas vraiment ... J'ai une petite idée ... Peut-être parce que je commençais à faire pas mal de dll et de so ...

        c'est a dire ?
        dois-je comprendre que tu as arreter d'utiliser un debugger quand la structure de tes programmes rendait difficile l'usage d'un debugger ?

        je debug des dll tous les jours, et ca va
        • [^] # Re: Difficile de répondre...

          Posté par  . Évalué à 2.

          C'est peut-être ça ... la flemme de suivre les threads dans les dlls ... les tls ... le bordel, quoi ...
          • [^] # Re: Difficile de répondre...

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

            vi,
            je sais bien de quoi tu parles,
            celà dit, sous windows, puisqu'on parle de ca, ya des mecanismes efficaces, pas evidents à mettre en place, c'est vrai, moi meme, comme toi j'ai fais pas mal de log au debut, mais une fois que tu arrives a utiliser un debugeur, c'est quand meme plus efficace
            enfin voilà, faut s'en donner la peine, perso je bosse sur des isapi, donc multithread, et ca marche
    • [^] # Re: Difficile de répondre...

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      - Si tu utilises des printf (ou assimilé) à la place, dis toi que Linus fait pareil. Donc c'est grave.

      Ouf...

      Je n'ai jamais utilisé de deboggueurs, trouvant que rien n'est plus facile à manier que des centaines de printf bien placés qui racontent des tas de trucs...

      Donc finalement, c'est pas si mal :-)

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Difficile de répondre...

        Posté par  . Évalué à 2.

        Y'a des fois où je me dis que c'est plus long de sortir le deboggueur que d'ajouter quelques lignes qui ensuite, effectivement, te servent pour blablater ...
      • [^] # Re: Difficile de répondre...

        Posté par  . Évalué à 3.

        Va t'amuser a trouver ce qui corrompt un emplacement memoire avec des printfs...

        Les debuggers c'est _essentiel_ si tu veux etre efficace, les printf c'est mignon au debut mais ca atteint tres vite ses limites niveau vitesse de debuggage et capacites.
        • [^] # Re: Difficile de répondre...

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

          Toutafé !

          J'ai identifié des bugs dans un programme à coups de

          (gdb) watch *((mon_type *)0x12345678)

          alors qu'au "printf", j'aurais eu aussi vite fait de me sauter par la fenêtre tout de suite ;-)

          Autre exemple classique : Le programme qui plante dans "get_value()" qui est appelé à 42 endroits différents du programme. En débuggant au printf, il faut 42 printf. Avec gdb, on tappe "up", et on a la réponse.

          Ceci dit, je fais aussi du débug au printf car malheureusement, mon débugger (gdb) est beaucoup moins fiable que mon compilateur (gcc).
    • [^] # Re: Difficile de répondre...

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

      >- Si tu utilises des printf (ou assimilé) à la place, dis toi que Linus fait pareil. Donc c'est grave.

      Oui, enfin, c'est sans compter sur le principe d Heisenberg.
      # Le programme tourne sous le debugger, mais pas sur la ligne de commande
      # Le programme marche quand tu rajoute des printf() pour débugger, mais pas si tu les enleves
      # Le programme marche quand des techniques de controle de bug sont appliquées, mais pas quand on les retire pour le mettre sur le marché.
      • [^] # Re: Difficile de répondre...

        Posté par  . Évalué à 1.

        Je ne pense pas que les phénomèmes que tu signales ressortent du principe d'Heisenberg, mais bien plutôt d'un principe que nous pourrions appeler de "certitude": une fois que le programme tourne, muni des outils de déverminage (quels qu'ils soient) il suffit d'enlever ces mêmes outils pour que le programme ne tourne plus ...
        Plus sérieusement, je n'utilise pas et n'ai jamais utilisé de debugger, la raison: la flemme d'apprendre à en utiliser un, toujours plus ou moins abscons. En C/C++, un mélange de printf (cout) et de compilation conditionnelle suffit amplement à mon bonheur.
      • [^] # Re: Difficile de répondre...

        Posté par  . Évalué à 1.

        # Le programme marche quand tu rajoute des printf() pour débugger, mais pas si tu les enleves

        J'utilise les cout et j'ai eu un jour une très mauvaise surprise car j'étais en train d'arrêter un thread et il s'est terminé anormalement (plutôt bloqué) car j'avais des points de synchronisation dans les logs avec un mutex et que "Aucune des primitives relatives aux mutex n'est un point d'annulation" ...
      • [^] # Re: Difficile de répondre...

        Posté par  . Évalué à 2.

        On général, il s'agit d'un problème mémoire qui se déplace avec l'ajout/supression de code. Dans ce cas, je ne connais que Electic Fence qui soit efficace (avec printf ou débugger)
  • # Quelqu'un a un bon tuto ?

    Posté par  . Évalué à 3.

    Ca me fait penser : est-ce que quelqu'un a un[des] bon[s] tutorial[aux] pour gdb ?

    Moi j'ai ca [1], mais si quelqu'un a mieux...

    C'etait le moment "echange tes marque-ta-page", un moment offert par le W3C (mais rendu possible par le CERN).

    [1] : http://www.dirac.org/linux/gdb/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.