Est-il possible de reculer dans pdb?
Après avoir appuyé sur n pour évaluer une ligne, je veux revenir en arrière, puis appuyer sur s pour accéder à cette fonction en cas d'échec. Est-ce possible?
Les documents disent:
j (ump) lineno Définissez la prochaine ligne qui sera exécutée. Disponible uniquement dans le cadre le plus bas. Cela vous permet de revenir en arrière et d'exécuter de nouveau le code, ou de sauter en avant pour ignorer le code que vous ne souhaitez pas exécuter.
Le débogueur GNU, gdb: il est extrêmement lent, car il annule une seule instruction machine à la fois.
Le débogueur Python, pdb: la commande jump vous fait reculer dans le code, mais n'inverse pas l'état du programme.
Pour Python, le prototype de débogueur étendu python, epdb, a été créé pour cette raison. Voici le thèse et voici le programme et le code .
J'ai utilisé epdb comme point de départ pour créer un débogueur inverse en direct dans le cadre de mon diplôme de maîtrise. La thèse est disponible en ligne: Combiner le débogage inverse et la programmation en direct vers la pensée visuelle dans la programmation informatique . Dans les chapitres 1 et 2, je couvre également la plupart des approches historiques du débogage inversé.
PyPy a commencé à implémenter RevDB , qui prend en charge le débogage inverse.
Il est (en février 2017) toujours à un stade alpha, ne prend en charge que Python 2.7, ne fonctionne que sur Linux ou OS X, et vous oblige à construire Python = vous d'une révision spéciale. C'est aussi très lent et utilise beaucoup de RAM. Pour citer la page Bitbucket:
Notez que le fichier journal augmente généralement à un taux de 1 à 2 Mo par seconde. En supposant que la taille n'est pas un problème, les facteurs limitants sont:
- Relecture du temps. Si votre exécution enregistrée a pris plus de quelques minutes, la relecture sera douloureusement lente. Il doit parfois parcourir plusieurs fois l'ensemble du journal en une seule session. Si le bogue se produit au hasard mais rarement, vous devez exécuter l'enregistrement pendant quelques minutes, puis tuer le processus et réessayer, à plusieurs reprises jusqu'à ce que vous obteniez le plantage.
- Utilisation de la RAM pour la relecture. Les exigences de RAM sont 10 ou 15 fois plus importantes pour la lecture que pour l'enregistrement. Si c'est trop, vous pouvez essayer avec une valeur inférieure pour MAX_SUBPROCESSES dans _revdb/process.py, mais cela sera toujours être plusieurs fois plus grand.
Les détails sont sur blog PyPy et les instructions d'installation et d'utilisation sont sur page RevDB bitbucket .
Le débogage inverse (retour à l'état d'application précédemment enregistré ou débogage à étape unique en arrière) est généralement une fonctionnalité de débogueur d'assemblage ou de niveau C. Par exemple. gdb peut le faire:
https://sourceware.org/gdb/wiki/ReverseDebug
débogage bidirectionnel (ou inversé)
Le débogage inverse est tout à fait complexe et peut entraîner une baisse des performances de 50 000x . Il nécessite également un support étendu des outils de débogage. Python ne fournit pas la prise en charge du débogage inverse.
Si vous évaluez de manière interactive Python code, je vous suggère d'essayer IPython Notebook qui fournit des shell interactifs HTML Python shells. Vous pouvez facilement écrire votre code et mélangez et faites correspondre la commande. Il n'y a pas de support de débogage pdb, cependant. Il y a ipdb qui fournit un meilleur historique et des fonctionnalités de recherche pour les commandes de débogage entrées, mais il ne fait pas non plus de sauts en arrière directs Pour autant que je sache.