web-dev-qa-db-fra.com

Pourquoi le débogage inverse est-il rarement utilisé?

gdb a implémenté le support de débogage inverse en 2009 (avec gdb 7.0). Je n'en ai jamais entendu parler avant 2012. Maintenant, je le trouve extrêmement utile pour certains types de problèmes de débogage. J'aurais aimé en avoir entendu parler auparavant.

Corrigez-moi si je me trompe mais j'ai l'impression que la technique est encore rarement utilisée et la plupart des gens ne savent pas qu'elle existe. Pourquoi?

Connaissez-vous des communautés de programmation où l'utilisation du débogage inverse est courante?

Informations d'arrière-plan:

debugging
57
Philipp Claßen

D'une part, le fonctionnement en mode débogage avec enregistrement activé est très cher par rapport au mode débogage même normal; il consomme également beaucoup plus de mémoire.

Il est plus facile de diminuer la granularité du niveau ligne au niveau appel de fonction. Par exemple, le débogueur standard dans Eclipse vous permet de "passer à l'image", qui est essentiellement un retour au début de la fonction avec une réinitialisation de tous les paramètres (rien de fait sur le tas n'est inversé et finally les blocs ne sont pas exécutés, il ne s'agit donc pas d'un vrai débogueur inversé; faites attention à cela).

Notez que cela est disponible depuis plusieurs années et fonctionne de pair avec le remplacement de code à chaud.

27
ratchet freak

Comme déjà mentionné, les performances sont essentielles, par exemple avec le débogage réversible de gdb, exécuter quelque chose comme gzip voit un ralentissement de 50 000x par rapport à une exécution native. Il existe cependant des alternatives commerciales: je travaille pour Undo ndo.io , et notre produit UndoDB fait de même mais avec un ralentissement inférieur à 2x. Il existe également d'autres débogueurs réversibles commerciaux.

11
user1839284

Pour un aperçu des choix technologiques et des produits, consultez une série d'articles de blog que j'ai écrits il y a environ un an (et quelques suivis depuis):

Mon sentiment pour pourquoi il est si peu utilisé est qu'il nécessite un matériel spécial, ou l'utilisation d'un débogueur spécial, ou une configuration correcte de votre système. La plupart des gens n'investissent pas le temps de tirer le maximum de leurs outils de débogage, malheureusement.

Et le fait que la "valeur par défaut bon marché" de gdb est presque inhabituellement lente et a pas mal de problèmes de stabilité pour tout sauf les systèmes cibles les plus courants.

10
jakobengblom2

D'après mon expérience en tant qu'ingénieur commercial pour le débogueur TotalView, les gens savent qu'il existe mais ils ne pensent pas que cela fonctionne, quel que soit le ralentissement (acceptable ou non).

L'Université de Cambridge a récemment mené une enquête intitulée "Échec de l'adoption des coûts de débogage inversés, économie mondiale de 41 milliards de dollars par an" .

Et en revenant à GDB, j'ai entendu (beaucoup) que le ralentissement le rend tout à fait inutilisable sur une application "réelle".

J'adorerais personnellement entendre plus de personnes utilisant le débogage inverse sur des applications autres que "Hello world!"

4
SebGR

Je pense qu'il est important d'étendre un peu plus loin ce débogage "inverse" ou "historique". Je pense que comprendre des systèmes et des comportements complexes dans ceux-ci, rejouer des "événements" qui rendent l'état explicite est absolument crucial.

Ce que je veux exprimer, c'est que vous n'êtes pas seuls à vous demander pourquoi cette technique n'est pas tellement appliquée aujourd'hui ou pourquoi les problèmes connexes sont rarement discutés clairement.

Soulignons donc ici deux concepts très importants:

Pour comprendre un système de programmation, il est utile de rendre l'état explicite

2.Pour encore mieux comprendre un système de programmation, la lecture de séquences d'état (événements) peut être très utile.

Voici quelques sources qui ont abordé le problème et proposé ou conçu des solutions au problème (traitant de l'état dans des systèmes complexes):

-En dehors du bit tar, papier: http://shaffner.us/cs/papers/tarpit.pdf Idées principales: éviter, isoler ou rendre l'état explicite

-CQRS http://www.cqrs.nu/ Il s'agit d'une combinaison de deux concepts: séparation des requêtes de commande et sourcing des événements. Il existe différentes implémentations (Java, C #, Scala). La relecture des séquences Tate et l'évolution d'un modèle de domaine sont les éléments cruciaux ici.

Si vous vraiment faites un zoom arrière et voyez l'image très large, vous pouvez déjà voir qu'avec la "montée" de la programmation fonctionnelle, les gens sont déjà ((in) consciemment ) attiré par fp car il rend l'état explicite! Mais cela ne concerne que le premier point, pour répondre au second, vous avez besoin d'un autre concept qui pourrait être décrit "vaguement" comme une programmation réactive fonctionnelle.

Donc, vous pourriez dire très bien, mais qui utilise réellement CQRS et FRP? Je dirais (l'OMI parce que je n'ai pas de chiffres concrets) en fait, beaucoup d'entreprises c'est juste qu'elles ne connaissent pas le travail qu'elles font a cette terminologie. Peut-être que vous cherchez un peu sur Google et que vous entendez des entreprises qui utilisent le CQRS, il y a déjà quelques succès. FRP augmente également lentement comme exemple, je pourrais donner à Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html Qui vient de publier une implémentation de RX qui est en fait basé sur .NET (mais a également une implémentation Javascript). Donc, les gens utilisent déjà ces techniques aujourd'hui, IN THE LARGE pour comprendre des systèmes complexes et les rendre encore meilleurs. C'est pourquoi ils utilisent des techniques de débogage inverse.

2
AndreasScheinert