Problèmes avec Emacs pdb et points d'arrêt dans le code Python multi-thread

Question

Je suis en cours d'exécution Emacs 23.2 python.el et le débogage du code Python avec pdb.

Mon code génère un thread d'frères et soeurs à l'aide du module threading et je mis un point d'arrêt au début de la méthode run(), mais la pause est jamais traitée par pdb même si le code fonctionne vraiment et fonctionne pour toutes fins utiles.

J'avais l'impression que je pouvais utiliser pdb pour établir des points d'arrêt dans any fil, même si plein débogage multithread est en fait pas pris en charge.

Suis-je tort de supposer pdb dans un M-x pdb invocation peut casser dans ne importe quel fil? Si vous ne me croyez pas essayer cet exemple minimal pour vous-même.

import threading

class ThreadTest(threading.Thread):
    def __init__(self,):
        threading.Thread.__init__(self)

    def run(self):
        print "Type M-x pdb, set a breakpoint here then type c <RET>..."
        print "As you can see it does not break!"

if __name__ == '__main__':
    tt = ThreadTest()

    tt.start()

Merci à Pierre et le texte du livre, il fait référence, j'ai essayé la possibilité d'inclure pdb.set_trace() comme suit:

def run(self):
    import pdb; pdb.set_trace()
    print "Set a breakpoint here then M-x pdb and type c..."

Mais cela ne les pauses et les offres pdb commandes pour étape, ensuite, continuer etcetera, si elle est exécutée à partir d'une console et d'exécuter directement dans l'interpréteur Python, et crucialement pas via Mx pdb - au moins avec ma configuration Emacs et pdb.

Alors, ma première question pourrait être reformulée faire avec:

Est-il possible d'invoquer un programme Python depuis Emacs, où que programme utilise inline invocation de pdb (soutenant ainsi les pauses dans les applications multi-thread), et pour qu'il y ait un tampon contrôle COMINT pdb établie automatiquement par magie?

ou

Si je lance mon application Python en utilisant Mx pdb et il contient un appel en ligne de pdb, la meilleure façon de gérer le fait que cela se traduit par une pdb-session-dans-un-pdb session avec la perte associée de contrôle?

Answer 1

Utilisez-vous le python.el par défaut? J'ai abandonné cette idée et commencé à utiliser python-mode.el. Ensuite, tapez M-x shell, à partir du python myproblem.py de type rapide (remplacer par votre nom de programme bien sûr) et il arrêtera à la ligne de set_trace. Il fonctionne hors de la boîte avec l'intégration pdb. (Et cela fonctionne sur votre programme).

Answer 2

Voir http://heather.cs.ucdavis.edu/ ~ Matloff / 158 / PLN / ParProcBook.pdf , il y a une section sur le débogage multithread.

3.6.1 Using PDB to Debug Threaded Programs
Using PDB is a bit more complex when threads are involved. One cannot, for instance, simply do something
like this:
pdb.py buggyprog.py
because the child threads will not inherit the PDB process from the main thread. You can still run PDB in
the latter, but will not be able to set breakpoints in threads.
What you can do, though, is invoke PDB from within the function which is run by the thread, by calling
pdb.set trace() at one or more points within the code:
import pdb
pdb.set_trace()
In essence, those become breakpoints.
For example, in our program srvr.py in Section 3.1.1, we could add a PDB call at the beginning of the loop
in serveclient():
while 1:
import pdb
pdb.set_trace()
# receive letter from client, if it is still connected
k = c.recv(1)
if k == ’’: break
You then run the program directly through the Python interpreter as usual, NOT through PDB, but then the
program suddenly moves into debugging mode on its own. At that point, one can then step through the code
using the n or s commands, query the values of variables, etc.
PDB’s c (“continue”) command still works. Can one still use the b command to set additional breakpoints?
Yes, but it might be only on a one-time basis, depending on the context. A breakpoint might work only once,
due to a scope problem. Leaving the scope where we invoked PDB causes removal of the trace object. Thus
I suggested setting up the trace inside the loop above.