Hallo,
ich habe Qt Creator 2.0 unter OpenSuse 10.3 mit dem mitgelieferten Qt 4.3.1 laufen und versuche nun, eine Anwendung zu debuggen. Ich kann im Quelltext gleich zu Beginn in main() aber Haltepunkte setzen, soviel ich will, das Programm hält einfach nicht an.
Hat es eine Bedeutung, dass das Haltepunktsymbol vor der Zeile nicht nur aus einem roten ausgefüllten Kreis besteht, sondern noch ein kleines lila farbenes Ding unten rechts dranhängt? Mit viel Interpretation könnte es eine kleine Sanduhr sein, aber sicher kann man das nicht sagen. Was bedeutet das? Einen Tooltip gibt es ja nicht.
Die einzige Variable an dem System ist Qt Creator, den hab ich direkt vom Hersteller nachinstalliert. Der Rest ist leider nicht änderbar (Projektanforderung).
Qt Creator ignoriert Haltepunkte
Re: Qt Creator ignoriert Haltepunkte
Klingt so, als wuerdest Du versuchen. etwas ohne Debug-Information zu debuggen, also z.B. etwas im "Release"-Mode gebautes.
[Das soll eine Sanduhr sein, es hat was zu sagen, warum es das sagt, laesst sich am besten anhand des Debugger-Logs (rechte Seite von Windows->Views->Debugger) feststellen]
[Das soll eine Sanduhr sein, es hat was zu sagen, warum es das sagt, laesst sich am besten anhand des Debugger-Logs (rechte Seite von Windows->Views->Debugger) feststellen]
-
LonelyPixel
- Beiträge: 23
- Registriert: 5. Juli 2008 23:21
Also wenn ich mit CONFIG += release bzw. debug einstellen kann, ob es ein Debug-Build wird, dann hab ich es mit beidem versucht. Wobei ich es von Windows auch gewohnt wäre, einen Release-Build debuggen zu können (auch wenn der sich im Einzelschritt aufgrund der Optimierungen gelegentlich etwas sprunghaft verhält).
Das mit dem Log muss ich morgen mal anschauen, wusste ich noch nicht.
Das mit dem Log muss ich morgen mal anschauen, wusste ich noch nicht.
-
LonelyPixel
- Beiträge: 23
- Registriert: 5. Juli 2008 23:21
Also, ich hab nun mal ins das Debugger-Log geschaut und Zeilen der folgenden Art gefunden:
ATTEMPT BREAKPOINT SYNC
130-break-insert "\"Main.cpp\":9"
...
&"No source file named Main.cpp.\n"
130^error,msg="No source file named Main.cpp."
Das gleiche passiert, wenn ich unter Extras, Einstellungen, Debugger, Gdb die Option "Vollständige Pfadinformation beim Setzen der Haltepunkte verwenden" aktiviere. Das Binary liegt in einem anderen Verzeichnis als der Code (ein Unterverzeichnis). Kann man diese Option in Qt Creator irgendwie reparieren, damit sie tut, was sie will, und das Problem damit evtl. beheben?
PS: Außerdem will Qt Creator dem gdb irgendwas mit python erzählen, woraufhin gdb meldet "Undefined command: \"python\". Try \"help\"." Python ist aber installiert und lässt sich aus dem terminal normal aufrufen. Warum stellt sich gdb hier so dämlich an? Wofür ist der gdb-Befehl "interpreter-exec" überhaupt gut? Der wird vor dem Programmstart 3x angegeben.
Außerdem hab ich nach dem "break-insert" jetzt noch das gleiche mit "break" gefunden.
ATTEMPT BREAKPOINT SYNC
130-break-insert "\"Main.cpp\":9"
...
&"No source file named Main.cpp.\n"
130^error,msg="No source file named Main.cpp."
Das gleiche passiert, wenn ich unter Extras, Einstellungen, Debugger, Gdb die Option "Vollständige Pfadinformation beim Setzen der Haltepunkte verwenden" aktiviere. Das Binary liegt in einem anderen Verzeichnis als der Code (ein Unterverzeichnis). Kann man diese Option in Qt Creator irgendwie reparieren, damit sie tut, was sie will, und das Problem damit evtl. beheben?
PS: Außerdem will Qt Creator dem gdb irgendwas mit python erzählen, woraufhin gdb meldet "Undefined command: \"python\". Try \"help\"." Python ist aber installiert und lässt sich aus dem terminal normal aufrufen. Warum stellt sich gdb hier so dämlich an? Wofür ist der gdb-Befehl "interpreter-exec" überhaupt gut? Der wird vor dem Programmstart 3x angegeben.
Außerdem hab ich nach dem "break-insert" jetzt noch das gleiche mit "break" gefunden.
-
LonelyPixel
- Beiträge: 23
- Registriert: 5. Juli 2008 23:21
Ähm, jetzt funktioniert es. Ich habe das compilierte Binary mal gelöscht, damit es sicher neu erstellt werden musste. Danach hat das Debuggen mit Haltepunkten auch funktioniert. Anscheinend war das Projekt früher mal auf Release eingestellt und die Änderung des Projekts hat Qt nicht dazu veranlasst, auch mal das Compilieren zu wiederholen...
Qt Creator muss mit einer ganzen Menge von gdb-Versionen klarkommen, die unterschiedliche Features und unterschiedliche Bugs haben. Ohne das "-interpreter-exec" schmiert z.B. der Apple-gdb glatt ab, wenn ein ihm unbekanntes Kommando wie z.B. "python" verlangt wird. Auf einem FSF-gdb ist es nicht noetig, schadet aber auch nicht. Aehnlich ist mit dem "-break-insert", das auf manchen Systemen nicht vorhanden ist bzw. nicht funktioniert, so dass "break" als Fallback verwendet wird.
Das "python" bezieht sich dabei auf eine gdb-Erweiterung (das "python" steht auf der gdb-Kommandozeile, nicht in der Shell!), die seit gdb 7.0 standardmaessig vorhanden ist. Damit kann man auf bestimmte gdb-interne Datenstrukturen durch Python-Skripte zugreifen. Das ist ziemlich maechtig und wird von Qt Creator auch ausgenutzt, wenn es vorhanden ist (google mal nach "qt peek poke vol3"). Wenn es wie bei Dir (zu alter gdb?) nicht da ist, gibt es auch da "Notfallvarianten".
Das "python" bezieht sich dabei auf eine gdb-Erweiterung (das "python" steht auf der gdb-Kommandozeile, nicht in der Shell!), die seit gdb 7.0 standardmaessig vorhanden ist. Damit kann man auf bestimmte gdb-interne Datenstrukturen durch Python-Skripte zugreifen. Das ist ziemlich maechtig und wird von Qt Creator auch ausgenutzt, wenn es vorhanden ist (google mal nach "qt peek poke vol3"). Wenn es wie bei Dir (zu alter gdb?) nicht da ist, gibt es auch da "Notfallvarianten".