webentwicklung-frage-antwort-db.com.de

pydev-Haltepunkte funktionieren nicht

Ich arbeite an einem Projekt mit Python 2.7.2, SQLalchemy 0.7, Unittest, Eclipse 3.7.2 und Pydev 2.4. Ich setze Haltepunkte in Python-Dateien (Unit-Test-Dateien), aber sie werden vollständig ignoriert (bevor sie irgendwann funktionierten). Inzwischen habe ich die gesamte zugehörige Software aktualisiert (siehe oben), neue Projekte gestartet, mit Einstellungen herumgespielt, meinen Bildschirm hypnotisiert, aber nichts funktioniert.

Die einzige Idee, die ich von einem Post bekommen habe, ist, dass es etwas zu tun hat, indem einige .py-Dateinamen in Kleinbuchstaben geändert werden.

Hat jemand irgendwelche Ideen?

hinzugefügt: Ich habe sogar die Aptana-Version von Eclipse installiert und die .py -Dateien darauf kopiert => dasselbe Ergebnis; Haltepunkte werden weiterhin ignoriert.

immer noch kein Fortschritt: Ich habe einen Code geändert, der als ungewöhnlich angesehen werden könnte, und ihn durch eine einfachere Lösung ersetzt.

einige weitere Infos: es hat wahrscheinlich etwas mit dem Modul unittest zu tun:

  • haltepunkte in meinen Dateien, die Testsuiten definieren, funktionieren,
  • haltepunkte in den unittest-Standarddateien selbst funktionieren
  • haltepunkte in meinen Testmethoden in von unittest.TestCase abgeleiteten Klassen funktionieren nicht
  • haltepunkte in meinem Code, die in den Testfällen getestet werden, funktionieren nicht
  • irgendwann, bevor ich funktionierende breakpoints in testmethoden oder im zu testenden code definieren konnte
  • einige Dinge, die ich danach geändert habe, sind: angefangen, Testsuiten zu verwenden, einige Dateinamen in Kleinbuchstaben geändert, ...
  • dieses Problem tritt auch auf, wenn mein Code ohne Ausnahmen oder Testfehler funktioniert.

was ich schon ausprobiert habe ist:

  • .pyc dateien entfernen
  • definiere ein neues Projekt und kopiere nur .py Dateien dorthin
  • zwischendurch mehrmals neu gestartet
  • auf Eclipse 3.7.2 aktualisiert
  • hat das neueste pydev auf Eclipse 3.7.2 installiert
  • zu aptana wechseln (und zurück)
  • code entfernt, der meinem Modul 'manuell' Klassen hinzugefügt hat
  • spielte mit einigen Konfigurationen

was ich noch tun kann ist:

  • starte ein neues Projekt mit meinem Code, entferne/ändere den Code, bis die Haltepunkte funktionieren und finde heraus, ob dies etwas mit einem Teil meines Codes zu tun hat

  • Hat jemand eine Idee, was diese Probleme verursachen oder wie sie gelöst werden könnten?
  • Gibt es einen anderen Ort, an dem ich nach einer Lösung suchen könnte?
  • Untersuchen die Entwickler von pydev die Fragen zum Stackoverflow?
  • Gibt es eine ältere Version von Pydev, die ich versuchen könnte?

Ich habe lange mit pydev/Eclipse gearbeitet und es funktioniert gut für mich, aber ohne Debugging musste ich die IDE wechseln.

Als Antwort auf Fabios Fragen unten:

  • Die Python-Version ist 2.7.2,
  • Die sys.gettrace gibt None (aber ich habe keine Ahnung, was in meinem Code das beeinflussen könnte)
  • Dies ist die Ausgabe des Debuggers nach Änderung der vorgeschlagenen Parameter:

Pydev-Debugger:

starting
('Executing file ', 'D:\\.Eclipse\\org.Eclipse.platform_3.7.0_248562372\\plugins\\org.python.pydev.debug_2.4.0.2012020116\\pysrc\\runfiles.py')
('arguments:', "['D:\\\\.Eclipse\\\\org.Eclipse.platform_3.7.0_248562372\\\\plugins\\\\org.python.pydev.debug_2.4.0.2012020116\\\\pysrc\\\\runfiles.py', 'D:\\\\Documents\\\\Code\\\\Eclipse\\\\workspace\\\\sqladata\\\\src\\\\unit_test.py', '--port', '49856', '--verbosity', '0']")
('Connecting to ', '127.0.0.1', ':', '49857')
('Connected.',)
('received command ', '501\t1\t1.1')
sending cmd: CMD_VERSION 501    1   1.1

sending cmd: CMD_THREAD_CREATE 103  2   <xml><thread name="pydevd.reader" id="-1"/></xml>

sending cmd: CMD_THREAD_CREATE 103  4   <xml><thread name="pydevd.writer" id="-1"/></xml>

('received command ', '111\t3\tD:\\Documents\\Code\\Eclipse\\workspace\\sqladata\\src\\testData.py\t85\t**FUNC**testAdjacency\tNone')
Added breakpoint:d:\documents\code\Eclipse\workspace\sqladata\src\testdata.py - line:85 - func_name:testAdjacency
('received command ', '122\t5\t;;')
Exceptions to hook : []
('received command ', '124\t7\t')
('received command ', '101\t9\t')
Finding files... done.
Importing test modules ... testAtomic (testTypes.TypeTest) ... ok
testCyclic (testTypes.TypeTest) ... 

Der Rest wird vom Komponententest ausgegeben.

Fortsetzung von Fabios Antwort Teil 2:

Ich habe den Code zu Beginn des Programms hinzugefügt, und der Debugger funktioniert nicht mehr in der letzten Zeile der Methode in sqlalchemy\orm\attributes.py (es ist ein Deskriptor, aber wie oder ob er das Debuggen stört, kann ich nicht beurteilen aktuelles Wissen):

class InstrumentedAttribute (QueryableAttribute): "" Klassengebundenes instrumentiertes Attribut, das Deskriptormethoden hinzufügt. ""

def __set__(self, instance, value):
    self.impl.set(instance_state(instance), 
                    instance_dict(instance), value, None)

def __delete__(self, instance):
    self.impl.delete(instance_state(instance), instance_dict(instance))

def __get__(self, instance, owner):
    if instance is None:
        return self

    dict_ = instance_dict(instance)
    if self._supports_population and self.key in dict_:
        return dict_[self.key]
    else:
        return self.impl.get(instance_state(instance),dict_) #<= last line of debugging

Von dort geht der Debugger in die __getattr__ -Methode einer meiner Klassen über, die aus einer declarative_base () -Klasse von sqlalchemy abgeleitet wurde.

Wahrscheinlich gelöst (wenn auch nicht verstanden):

Das Problem schien zu sein, dass der oben erwähnte __getattr__ etwas Ähnliches wie eine unendliche Rekursion erzeugte, jedoch das Programm/unittest/sqlalchemy wiederherstellte, ohne einen Fehler zu melden. Ich verstehe den sqlalchemy-Code nicht ausreichend, um zu verstehen, warum die __getattr__-Methode aufgerufen wurde.
Ich habe die __getattr__-Methode geändert, um super für den Attributnamen aufzurufen, für den die Rekursion aufgetreten ist (wahrscheinlich nicht meine endgültige Lösung), und das Haltepunktproblem scheint verschwunden zu sein. Wenn ich das Problem präzise formulieren kann, werde ich wahrscheinlich versuchen, mehr Informationen über die Google SQL-Chemie-Newsgroup zu erhalten, oder zumindest meine Lösung auf Robustheit zu überprüfen.

Vielen Dank, Fabio, für Ihre Unterstützung. Die trace_func () -Funktion hat das Problem für mich genau bestimmt.

22
Lars

Scheint wirklich seltsam ... Ich benötige weitere Informationen, um das Problem besser zu diagnostizieren:

Öffnen Sie\plugins\org.python.pydev.debug\pysrc\pydevd_constants.py und ändern Sie

DEBUG_TRACE_LEVEL = 3 
DEBUG_TRACE_BREAKPOINTS = 3

führen Sie Ihren Anwendungsfall mit dem Problem aus und fügen Sie die Ausgabe Ihrer Frage hinzu ...

Es kann auch sein, dass aus irgendeinem Grund die Debugging-Funktion in einer von Ihnen verwendeten Bibliothek oder in Ihrem Code zurückgesetzt wird. Gehen Sie dazu wie folgt vor: An derselben Stelle, an der Sie den Haltepunkt setzen würden, tun Sie Folgendes:

import sys
print 'current trace function', sys.gettrace()

(Hinweis: Wenn Sie im Debugger ausgeführt werden, ist zu erwarten, dass die Trace-Funktion wie folgt lautet: <bound method PyDB.trace_dispatch of <__main__.PyDB instance at 0x01D44878>>)

Bitte geben Sie auch an, welche Python-Version Sie verwenden.


Antwort Teil 2:

Die Tatsache, dass sys.gettrace () None zurückgibt, ist wahrscheinlich das eigentliche Problem ... Ich kenne einige externe Bibliotheken, die sich damit herumschlagen (zB: DecoratorTools - read: http://pydev.blogspot.com/2007/06 /why-cant-pydev-debugger-work-with.html ) und haben sogar Python-Bugs gesehen und kompilierte Erweiterungen brechen es ...

Der häufigste Grund dafür ist jedoch wahrscheinlich, dass Python im Hintergrund die Ablaufverfolgung (und damit den Debugger) deaktiviert, wenn eine Rekursion einen Stapelüberlauffehler auslöst (dh: RuntimeError: maximale Rekursion) Tiefe überschritten).

Sie können wahrscheinlich ganz am Anfang Ihres Programms einen Haltepunkt setzen und den Debugger so lange aufrufen, bis er nicht mehr funktioniert.

Oder vielleicht ist das Folgende einfacher: Fügen Sie den folgenden Code ganz am Anfang Ihres Programms ein und sehen Sie, wie weit er mit dem Drucken geht ... Das letzte, was gedruckt wird, ist der Code, kurz bevor er kaputt geht (Sie könnten also einen Haltepunkt bei setzen Die letzte gedruckte Zeile sollte die letzte Zeile sein, in der sie funktionieren würde. Beachten Sie, dass das Drucken bei großen Programmen möglicherweise sehr lange dauert. Es kann sogar sein, dass das Drucken in eine Datei schneller erfolgt als in eine Konsole (z B. cmd, bash oder Eclipse) und späteres Öffnen dieser Datei (leiten Sie den Ausdruck vom Beispiel in eine Datei um).

import sys

def trace_func(frame, event, arg):
    print 'Context: ', frame.f_code.co_name, '\tFile:', frame.f_code.co_filename, '\tLine:', frame.f_lineno, '\tEvent:', event
    return trace_func

sys.settrace(trace_func)

Wenn Sie es immer noch nicht herausfinden können, veröffentlichen Sie bitte weitere Informationen zu den erzielten Ergebnissen ...

Hinweis: Sie können Folgendes umgehen, bis Sie den tatsächlichen Ort nicht mehr finden:

import pydevd;pydevd.settrace()

an der Stelle, an der Sie den Haltepunkt setzen würden - auf diese Weise hätten Sie einen Haltepunkt im Code, der auf jeden Fall funktionieren sollte, da an dieser Stelle die Tracefunktion festgelegt werden muss (dies ist dem Remote-Debugging sehr ähnlich: http://pydev.org/manual_adv_remote_debugger.html Da der Debugger jedoch bereits zuvor verbunden war, muss der Remote-Debugger nicht wirklich gestartet werden.

13
Fabio Zadrozny

Später ins Gespräch kommen, aber nur für den Fall, dass es hilft. Ich bin gerade auf ein ähnliches Problem gestoßen und habe festgestellt, dass der Debugger sehr speziell für w.r.t ist. welche Zeilen es als "ausführbar" ansieht und auf denen es unterbrochen werden kann.

Wenn Sie Zeilenfortsetzungen oder mehrzeilige Ausdrücke (z. B. innerhalb einer Liste) verwenden, setzen Sie den Haltepunkt in die letzte Zeile der Anweisung.

Ich hoffe, es hilft.

5
Miguel

Versuchen Sie, die entsprechende .pyc-Datei (kompiliert) zu entfernen und dann auszuführen. Außerdem habe ich manchmal festgestellt, dass ich mehr als eine Instanz eines Programms ausgeführt habe .. was pydev verwirrte. Ich habe das definitiv auch schon gesehen. Ziemlich oft.

2
Luke Codewalker

Ich hatte ähnlich klingende Symptome. Es stellte sich heraus, dass meine Modul-Importsequenz mein Einstiegspunkt-Python-Modul erneut ausführte, da eine binäre Bibliothek (keine Python-Bibliothek) dynamisch geladen werden musste, d. H. Der LD_LIBRARY_PATH wurde dynamisch zurückgesetzt. Ich weiß nicht, warum dies den Debugger veranlasst, nachfolgende Haltepunkte zu ignorieren. Möglicherweise gibt der rexec-Aufruf nicht debug = true an. sollte debug = true/false basierend auf dem aufrufenden Kontextstatus angegeben werden?

Versuchen Sie, bei Ihrer ersten Importanweisung einen Haltepunkt zu setzen, um festzustellen, ob Sie die Importe dann abarbeiten oder nicht. Wenn ich über den 3rd-Party-Import, der das dynamische Laden der Bibliothek erforderte, "weiter" würde, würde der Debug-Interpreter einfach nach allen Haltepunkten fortfahren.

1
Jim Coles

Stieß auf eine ähnliche Situation mit einer Django-App in Eclipse/pydev. Was geschah, war, dass der Code, der ausgeführt wurde, derjenige war, der in meiner virtuellen Umgebung installiert war, nicht mein Quellcode. Ich habe mein Projekt aus meinen virtuellen env-Site-Paketen entfernt, den Django im Eclipse/pydev-Debugger neu gestartet und alles war in Ordnung.

1