Comment puis-je dire d'où mon script python est suspendu?

Donc, je suis le débogage mon programme en python et ont rencontré un bug qui fait que le programme pendre, comme si dans une boucle infinie. Maintenant, j'ai eu un problème avec une boucle infinie avant, mais quand il a raccroché, je pouvais tuer le programme python et recraché un utile exception qui m'a dit où le programme fin quand je l'ai envoyé la commande kill. Maintenant, cependant, lorsque le programme se bloque et je ctrl-c, on ne va pas abandonner, mais continue de courir. Est-il un outil que je peux utiliser pour localiser l'accrocher? Je suis nouveau sur le profilage mais d'après ce que je sais un profileur ne peut vous fournir de l'information sur un programme qui a complété avec succès. Ou pouvez-vous utiliser un profiler pour déboguer tel hang ups?

  • Comment savez-vous qu'il est dans une boucle? Est un PROCESSEUR fixé à 100%? Si non, ça pourrait être dans une prise d'attente (en supposant que c'est de faire des e/S réseau).
  • Si elle ne répond pas à Ctrl+C, ce pourrait être parce que la KeyboardInterrupt exception est pris à un certain point. Si vous avez un try: ... except: clause qui n'a pas de nom spécifique des classes d'exception, qui pourrait être responsable.
  • J'ai exactement le même problème et Ctrl+C ne fonctionne pas car il se bloque à l'intérieur d'un C-appeler quelque part. Mon CPU est à 100%.
InformationsquelleAutor Johnny | 2010-08-09
  1. 87

    Supposons que vous exécutez votre programme:

    python YOURSCRIPT.py

    Essayez d'exécuter votre programme:

    python -m trace --trace YOURSCRIPT.py

    Et avoir de la patience alors que beaucoup de choses est imprimé sur l'écran. Si vous avez une boucle infinie, il sera pour toujours (problème de l'arrêt). Si ça coince quelque part, alors la plupart du temps vous êtes coincé sur les I/O ou c'est une impasse.

    • +1. Vous pouvez utiliser l'option --ignore-dir ou --ignore-module options pour réduire la quantité de production, par exemple pour arrêter le traçage à travers tous les modules standard. Vous pouvez également rediriger la sortie vers un fichier pour examen ultérieur.
    InformationsquelleAutor dhruvbird
  2. 26

    Wow! 5 réponses déjà et personne n'a suggéré la plus évidente et la plus simple:

    1. Essayer de trouver un reproductibles cas de test qui provoque la pendaison de comportement.
    2. Ajouter vous connecter à votre code. Ce peut être aussi élémentaire que print "**010", print "**020", etc. parsemées à travers les grands domaines.
    3. Exécuter du code. Voir où il se bloque. Ne peut pas comprendre pourquoi? Ajouter plus de journalisation. (I. e. si entre **020 et **030, aller et ajouter **023, **025, **027, etc.)
    4. Goto 3.

    Enfants ces jours-ci avec leur fantaisie débogueurs & IDEs... Parfois, l'ingénierie, les problèmes sont résolus plus simplement avec des outils primitifs, qui fournissent un peu plus d'informations.

    • +1, c'est ce que je fais souvent. Bien sûr, les débogueurs et IDEs sont utiles aussi, mais je trouve que c'est le moyen le plus rapide/facile à fixer l'emplacement d'un bug quand j'ai déjà une idée approximative de la partie de la source de chercher dans. (Juste mon avis, bien sûr)
    • Pour des scripts simples, sans grande complexité, cela fonctionne. Cependant, pour de longues, des programmes complexes, c'est inutile.
    • Pour les programmes complexes, de vous changer "**010" à "Démarrage de blaster module" et "**020" à "Connexion à la fusion de serveur", etc. Et le changement "imprimer" pour utiliser la fonction "enregistrement" du module. Si vous ne faites pas ceci, vous le faites mal.
    • nah, le code est trop grand. Ne peut pas aller autour de l'ajout des instructions d'impression, partout. il doit y avoir une meilleure réponse
    • Wow, tels blâmer.
    • Parfois, il n'est pas suspendu sur votre code, que si une extension C++ en suspens? Que faire si le projet repose sur d'énormes libs comme Tensorflow ou Keras, cette technique bien qu'intéressant pour certains cas, n'est pas applicable pour les autres.

    InformationsquelleAutor dkamins
  3. 9

    Si votre programme est trop gros et trop complexe pour être viable pour le pas à pas avec apb ou de l'impression de chaque ligne avec la trace du module, alors vous pourriez essayer un truc de mes jours de 8-bit jeux de programmation. À partir de Python 2.5 à partir de l'apb a la capacité d'associer le code avec un point d'arrêt à l'aide de la commands de commande. Vous pouvez utiliser cette option pour imprimer un message et poursuivre l'exécution:

    (Pdb) commands 1
(com) print "*** Breakpoint 1 ***"
(com) continue
(com) end
(Pdb)

    Ce affichera un message et d'effectuer en cours d'exécution lorsque le point d'arrêt 1 frappe. Définir des commandes similaires pour quelques autres points d'arrêt.

    Vous pouvez l'utiliser pour faire une sorte de recherche binaire de votre code. Fixez les points d'arrêt aux endroits clés dans le code et l'exécuter jusqu'à ce qu'il se bloque. Vous pouvez dire à partir du dernier message qui a été le dernier point d'arrêt il est frappé. Vous pouvez ensuite déplacer les autres points d'arrêt et de ré-exécuter pour affiner l'endroit dans le code où il se bloque. Rincer et répéter.

    Incidemment, sur les 8 bits micros (Commodore 64, Spectrum, etc), vous pouvez piquer une valeur dans un registre de localisation de changer la couleur de la bordure autour de l'écran. J'ai utilisé à quelques points d'arrêt pour ce faire avec des couleurs différentes, de sorte que lorsque le programme est exécuté, il donnerait un arc-en-ciel psychédélique écran jusqu'à ce qu'il pendait, la frontière se changerait en une seule couleur qui vous dit ce que le dernier point d'arrêt a été. Vous pouvez également obtenir une bonne idée de la performance relative des différentes sections de code par la quantité de chaque couleur de l'arc-en-ciel. Parfois je m'ennuie de la simplicité de ces nouvelles ultramodernes "Windows" machines.

    InformationsquelleAutor Dave Kirby
  4. 7

    J'ai écrit un module qui permet d'afficher fils qui pendent plus de 10 secondes à un endroit.
    hanging_threads.py

    Voici un exemple de sortie:

    --------------------    Thread 5588     --------------------
  File "C:\python33\lib\threading.py", line 844, in _exitfunc
        t.join()
  File "C:\python33\lib\threading.py", line 743, in join
        self._block.wait()
  File "C:\python33\lib\threading.py", line 184, in wait
        waiter.acquire()

    Cela se produit à la sortie du thread principal lorsque vous oubliez de définir un autre thread que daemon.

    • Cet outil est exactement ce que je cherche à trouver un buttleneck dans mon Django app sous uWSGI dans la production. Je pense qu'il vaut la peine d'être un paquet python. S'il vous plaît laissez-nous savoir si ce qui se passe dans le futur.
    • c'est un ensemble, maintenant: pypi.python.org/pypi/hanging_threads
    InformationsquelleAutor User
  5. 3

    Il est plus facile de prévenir ces hang-ups que c'est à déboguer.

    Première: for boucles sont très, très difficile à obtenir coincé dans une situation où la boucle ne sera pas résilié. Très dur.

    Deuxième: while boucles sont relativement faciles à obtenir coincé dans une boucle.

    La première étape est de vérifier tous les while boucle pour voir si il doit être un while boucle. Souvent, vous pouvez remplacer while avec des constructions de for, et vous pourrez corriger votre problème en repensant votre boucle.

    Si vous ne pouvez pas remplacer un while boucle avec for, puis il vous suffit de prouver que l'expression dans le while déclaration doit de changer à chaque passage dans la boucle. Ce n'est pas que difficile à prouver.

    1. Regardez tous les condition dans la boucle. Appel ce T.

    2. Regardez toutes les branches logiques dans le corps de la boucle. Est-il possible de passer à travers la boucle sans un changement d'état, T?

      • Oui? C'est un bug. Cette logique chemin est mauvais.

      • Pas? Excellente, cette boucle doit mettre fin.

    • Ceci est valable uniquement pour des applications monothread. J'ai eu des blocages, des courses et d'autres problèmes lors du développement d'applications Qt que l'utilisation de plusieurs threads e..g pour les signaux et les slots. Non, le GIL n'empêche pas tous de cette.
    • Je suis entièrement en désaccord. La prévention de hang-ups comme c'est quasiment impossible. Ces hang-ups vont inévitablement se produire. D'autre part, le débogage est presque toujours possible, et d'une importance fondamentale dans le cadre du développement de logiciel.
    InformationsquelleAutor S.Lott
  6. 3

    Si votre programme est un peu trop complexe pour être simplement la trace de toutes les fonctions, vous pouvez essayer de l'exécuter manuellement et de fixation d'un traceur programme comme lptrace à elle. Il fonctionne un peu comme strace– elle imprime à chaque appel de fonction de votre programme fait. Voici comment l'appeler:

    python lptrace -p $STUCK_PROGRAM_PID

    Noter que lptrace nécessite gdb pour les exécuter.

    • J'ai essayé ce lptrace. Maintenant, j'ai deux python processus de la pendaison. Mignon.
    InformationsquelleAutor Karim H
  7. 2

    Rien de tel que le bon vieux apb

    import pdb
pdb.run('my_method()',globals(),locals())

    Puis appuyez simplement sur (n) pour aller à la prochaine commande (s) à l'étape dans. voir la documentation pour la référence complète.
    Suivez votre programme étape par étape, et vous aurez probablement comprendre assez vite.

    • "et vous aurez probablement comprendre assez vite".... à moins que votre programme n'est pas petite.
    InformationsquelleAutor Ofri Raviv
  8. 2

    Vous pouvez également essayer de http://code.activestate.com/recipes/576515-debugging-a-running-python-process-by-interrupting/ . Il devrait fonctionner aussi longtemps que le Python processus n'a pas de signaux masqués, qui est normalement le cas, même si Ctrl-C ne fonctionne pas.

    InformationsquelleAutor Daira Hopwood
  9. 0

    Ne l'ai pas utilisé moi-même, mais j'ai entendu dire que le Eric IDE est bon et a un bon débogueur. C'est aussi le seul IDE je sais de qui a un débogueur pour Python

    • Aile IDE a aussi un bon débogueur - vivement recommandé. Ce qui concerne.
    • Eclipe IDE est également très bon
    InformationsquelleAutor Matti Lyra
  10. 0

    Si votre programme a plus d'un thread, il pourrait être ignorant ctrl-c, car le fil conducteur est connecté à la combinaison de touches ctrl-c gestionnaire, mais le live (runaway?) thread est sourd à elle. Le GIL (global interprète lock) dans Disponible signifie que normalement, un seul thread peut effectivement être en cours d'exécution à tout moment.
    Je pense que j'ai résolu mon (peut-être) le même problème à l'aide de cette

    InformationsquelleAutor phlip
  11. -1
    i = 0
for t in threading.enumerate():
    if i != 0:# and t.getName() != 'Thread-1':
        print t.getName()
        t._Thread__stop()
    i += 1

    Une fois que vous connaissez les noms des fils; début de la ré-exécution de votre script et le filtre vers le bas, ne pas s'arrêter d'être abandonnée. i=0 conditionnelle empêche le thread principal d'être abandonnée.

    Je suggère d'aller à travers et à nommer toutes vos fils; tels que:
    Thread(cible=auto.log_sequence_status, nom='journal le statut")

    Ce code doit être placé à la fin du programme principal qui démarre le processus de

    InformationsquelleAutor Justin Catterson
  12. -8

    Wow ! Semble que vous avez ajouté tellement de code dans un aller sans le tester que vous ne pouvez pas dire quel est le code a été ajoutée juste avant le programme a commencé à accrocher... (la cause la plus probable du problème).

    Au sérieux, vous devez le code par de petits pas et de tester chacun d'eux individuellement (idéalement faire TDD).

    Pour votre problème exact de repérer ce que le code python est en cours d'exécution et ctrl-c ne fonctionne pas, je vais essayer un cru deviner: avez-vous utilisé des except: attraper toutes les exceptions indistinctement. Si vous l'avez fait dans une boucle (et continue la boucle après la gestion de l'exception), c'est très probablement la raison pour laquelle ctrl-c ne fonctionne pas : il est piégé par cette exception. Changement de except Exception: et il ne devrait pas être atteint, plus il y a d'autres possibilités pour le ctrl+c ne fonctionne pas comme la gestion des threads comme une autre affiche a suggéré, mais je crois que la raison invoquée ci-dessus est plus probable).

    exception KeyboardInterrupt

    Raised when the user hits the interrupt key (normally Control-C or Delete).

    Lors de l'exécution, un chèque pour les interruptions sont régulièrement.
    Les interruptions tapé lors de la intégré dans la fonction input() ou raw_input() est
    en attente d'entrée également soulever cette exception. L'exception hérite
    de BaseException afin de ne pas être pris accidentellement par code
    les captures d'Exception et d'empêcher ainsi l'interprète de sortie.

    Changed in version 2.5: Changed to inherit from BaseException.
    • Je me demande quelle partie de cette réponse obtenu ce -1 deux ans après l'avoir écrit. Le dernier code ajouté est susceptible de causer le nouveau mauvais comportement, vous devez utiliser TDD, ou si les touches Ctrl+C ne répond pas au problème est susceptible d'être causée par la capture clavier exceptions (et probablement dans une boucle). Regarde comme il y a très peu évaluateurs de la qualité autour de...
    • mute les gens garder à downvote. Je suppose que c'est TDD despisers ou croyant que les grands programmes doit être écrit une fois et une seule course (et corrigés) lorsque vous avez terminé.
    • pas un downvoter, mais je peux voir pourquoi: si vous êtes à la recherche sur google pour obtenir de l'aide et de trouver cette page... pour la première partie c'est trop tard et pas utile, mais la deuxième partie est certainement correctes (et mérite un upvote) - d'être précis dans vos exceptions. Il pourrait même être à l'aide de TDD vous mettre dans des situations où le code se bloque, assurez-vous que c'est quelque chose depuis le dernier commit... mais ce. (FWIW, je vais avoir ce cas, le transfert d'une base de code à python 3, il est testé - et la plupart des tests à passer en ce moment - mais certains comportements étranges est à l'origine de "suspendu" dans un test).
    • Parfois problème se produit après quelques actions de l'utilisateur, pas après validation. Votre suggestion est bonne, mais pas pour tous les cas.
    • ce que vous dites est très rare, si vous utilisez les outils de couverture de code pour vérifier que tous les chemins sont couverts. Lorsqu'un problème se produire comme conséquence d'une action de l'utilisateur, j'ai l'habitude de l'appeler un "Problème de Sécurité". Et c'est mon travail d'écriture de logiciels de sécurité. L'utilisateur ne devrait pas être en mesure de fournir d'informations qui casse le code (mais je suis d'accord, il arrive parfois). Néanmoins: il n'a pas à être le dernier commit, même si c'est un ancien commit il peut être suivi à travers découpent. Mais seulement si commet ne sont pas trop grandes...
    • Malheureusement rare, mais douloureuse cas ne peuvent pas être suivis par découpent lorsque le problème se produit sur un très chargé serveur de production. Code complet de la couverture aussi ne garantit pas que nous avons couvert tous les états possibles qui peuvent être générés par imprévisible du comportement de l'utilisateur.. C'est vraiment rare, mais vraiment, vraiment douloureux cas )
    • Je suis d'accord, j'ai déjà eu ce genre de cas à résoudre. Heureusement très rares et très pénible. Mais l'utilisation de l'impression pour les traces ou pdb() comme suggéré par d'autres réponses ne sont pas vraiment utile si le blocage ne peut pas être reproduit à volonté. J'ai l'habitude d'utiliser des installations loging et les traces de pile pour l'analyse post mortem à cette fin.
    • Bien sûr, estampes et de la pdb() ne sera pas utile dans ce cas aussi. Je vais essayer le module proposé par @User qui vide la pile pour l'coincé fils, espérons que cela aidera. Il semble que cela devrait fonctionner pour tous les cas, y compris la douleur.
    • Si votre code commencé à traîner à cause d'un problème de réseau ou de certains de la bibliothèque C est défaillante, en regardant récemment ajouté le code ne va pas vous aider. Je ne vais pas downvote, mais ce conseil aide à que dans la plupart des cas triviaux.
    • Je suis totalement en désaccord avec ce que vous dites dans votre commentaire. La lecture que je me demande si vous êtes un développeur ? Peut-être plus d'un stylo testeur, un pirate ou un tel ? Lorsque vous écrivez du code de l'environnement externe n'est pas de changer par lui-même, votre code ne. Et à la place d'un bug git découpent est votre meilleur ami. Bien entendu, les choses sont complètement différentes pour repérer un bug de logiciel dans la nature (sur les sites des clients). Mais alors vous devez être vraiment de la chance d'être dans une position pour exécuter un débogueur ou d'un outil similaire. TDD et les petits commits sont aider bien quand il n'est pas trop tard pour le faire!
    • Je suis un développeur de logiciel, et, en fait, est venu ici à cause de problèmes du monde réel à un monde réel de la base de code. Dans le monde réel, les modifications de l'environnement par lui-même tout le temps. Par exemple, dans ce cas, le problème était que le datebase dans l'impasse, causant de Django à accrocher au démarrage. Il n'y avait pas de modifications du code, il était purement un problème dans la db. Juste parce que votre code ne doit pas au hasard arrêter de travailler quand vous n'avez pas touché, il ne signifie pas qu'il ne sera pas dans la pratique.
    • ne pas dire jamais qui se passe. Mais il est rare. La semaine dernière, j'ai par exemple correction d'un Problème dans la bibliothèque openssl (liées à l'API de changement entre 1.1 et 1.2 et un sans-papiers pour le changement de comportement). J'ai repéré par git bissecting le code de la bibliothèque... mais je n'accepte pas les modifications de l'environnement par lui-même. C'est l'environnement de production vs environnement de dev. Le plus tard est (ou devrait être) stable, l'ancien ne l'est pas. Si le verrou est liée ici à une base de données spécifique, elle aurait été banal pour spot que tout était ok avec la base de données de test et le code se bloque dans la base de données de production.

    InformationsquelleAutor kriss