Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Ich kenne Debuggen aus C++ Zeiten mit hochintegrierten IDEs. KlickiBuntu. Kein Problem.
Für Python3 nutze ich derzeit geany als IDE.
Hab auch diverse Sachen schon zu debuggern gegelesen, aber kann mit den shell-basierten Dingern nix anfangen. Weiß nicht, wie ich da debuggen soll.
Hab ein kleine Script, das einen "Speicherzugriffsfehler" macht. Wo fange ich da mit der Analyse an?
Speicherabbild sei geschrieben worden. Aha. Wie schau ich mir das an? Wohin?
@MoonKid: In Python debugged man am einfachsten, indem man an bestimmen Stellen die Werte von Variablen ausgeben läßt. Ein Speicherzugriffsfehler deutet auf einen Fehler in einer externen Bibliothek hin, da kommst Du mit Pythonmitteln sowieso nicht hin. Also ist entweder ein Fehler im Aufruf, oder in der Bibliothek.
@MoonKid: Speicherzugriffsfehler wird schwierig weil Python-Debugger ja auch in dem Python-Prozess laufen, so einen Speicherzugriffsfehler bekommst Du aber sehr wahrscheinlich nicht im Python-Code selbst sondern in einer Erweiterung die in C oder C++ geschrieben ist.
Für Python selber kann ich persönlich mit den klassischen Debuggern nichts anfangen weil man nicht mehr diese unübersichtlichen Funktionen oder Methoden mit tief verschachtelten Schleifen und vielen Indexvariablen hat wie in C zum Beispiel. Und das sind ja eigentlich die Sachen wo man eine Einzelschrittausführung braucht wenn man das im Kopf nicht mehr nachvollziehen kann ohne durcheinander zu kommen. Tracebacks führen einen, ausser bei harten Abstürzen wie in Deinem Fall, ziemlich direkt zu dem Punkt wo es gekracht hat. Da baut man dann ein paar ``print``\s oder `logging`-Ausgaben ein und findet so das Problem in der Regel recht schnell. Zusätzlich kann man den betroffenen Python-Code auch in einer interaktiven Shell ausprobieren und sehen welche Eingaben wo und welche Probleme verursachen.
Für die wenigen Fälle wo man dann doch mal Einzelschritte braucht gibt's mit WinPDB eine GUI für den Python-Debugger. Nicht vom Namen irritieren lassen: das ist Cross-Plattform und nicht nur für Windows. Ich habe das aber soweit ich mich erinnere nur einmal bisher tatsächlich benötigt, und das war für eine 1:1 portierte Version von einem komplex verschachtelten Algorithmus mit vielen Indexvariablen der ursprünglich mal in Pascal geschrieben wurde. Also sehr „unpythonischer” Quelltext.
@MoonKid: um zu wissen, wo es kracht, reicht es gdb zu nehmen und sich den backtrace anzuschauen. Beim Übergang vom Python-Executable zur C-Bibliothek ist die Funktion, die Du von Python heraus aufrufst, bei der dann irgend ein Fehler passiert.
gdb? Ok, hab ich hier. Aber was tu ich damit? ist auch nur eine "shell".
Darum geht es ja. Hab mit python noch nie gedebugged. Kann mir nicht mal vorstellen, wie sowas mit einer shell überhaupt funktionieren soll.
Kann gdb nicht mal beenden, außer mit Ctrl+Z.
MoonKid hat geschrieben:Ich kenne Debuggen aus C++ Zeiten mit hochintegrierten IDEs. KlickiBuntu. Kein Problem.
Eclipse mit PyDev: Du kannst Breakpoints setzen, step in und step over, in die Variablen reinschauen, deren Wert ändern und sogar den Code ändern (während des Debuggens).
@MoonKid: ``gdb`` kann man mit ``quit`` beenden. (Du hast ``gdb`` unter Windows installiert?)
Das was Du da jetzt versuchst ist aber eigentlich auch kein Python-Debugging mehr. Du müsstest ``gdb`` mit dem Programm und der Speicherabbilddatei zusammen laden und Dir dann den Traceback ausgeben lassen. Habe ich persönlich für ein Interpretiertes Programm noch nie gemacht. Und dann ist auch die Frage ob und wie viel Informationen man da überhaupt bekommt, also ob zum Beispiel die Symbole von den beteiligten Programmen und Bibliotheken überhaupt verfügbar sind und man nicht nur einen Haufen Adressen in Hexadezimalschreibweise ausgespuckt bekommt.
Ich würde ja erst einmal versuchen das Problem im Python-Quelltext durch Ausgaben einzugrenzen. Sehen bis zu welchem Aufruf das Programm kommt. Was ist das überhaupt für ein Programm? Welche externen Bibliotheken kommen denn für den Crash in Frage?
@MoonKid: Ich hatte mich ja schon über das Ctrl+Z gewundert: Damit hattest Du ``gdb`` nicht beendet sondern lediglich angehalten. Da wird die Jobnummer mit ausgegeben unter der die Bash diesen angehaltenen Prozess kennt und damit könnte man den Prozess dann tatsächlich beenden. Oder man könnte ihn mit ``fg`` auch wieder fortsetzen.
