Seite 1 von 2
Debug Error
Verfasst: 28. Juni 2006 08:04
von ConcordeLord
Hallo,
hab ein Probelm mit meinem Debugger. Wenn ich meine Applikation kompilieren werden keine Fehler angezeigt,
lass ich alles zusammen im Debug- Modus übersetzen, wird alles richtig gelinkt, erst beim laden der
Bibliotheken kommt der Fehler
"File: ...qglaobal.cpp - QWidget: Must construct a QApplication before a QPaintDevice"
"Press Retry to debug the application"
Wenn ich dann retry drücke, kommt der nächste Fehler "Applikation.exe hat einen Haltepunkt ausgelöst" und zeigt
dann auf die qglobal.cpp auf folgenden Codeausschnitt
#if defined(Q_CC_MSVC) && defined(QT_DEBUG) && defined(_DEBUG) && defined(_CRT_ERROR)
// get the current report mode
int reportMode = _CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_WNDW);
_CrtSetReportMode(_CRT_ERROR, reportMode);
int ret = _CrtDbgReport(_CRT_ERROR, __FILE__, __LINE__, QT_VERSION_STR, buf);
if (ret == 0 && reportMode & _CRTDBG_MODE_WNDW)
return; // ignore
else if (ret == 1)
_CrtDbgBreak();
#endif
Habe keine Ahnung was der Fehler sein könnte, da ich keinen QPaintDevice verwende. Hab schon probehalber alles
auskommentiert, wo ich gedacht hätte, dass das der Fehler sein könnte.
Hoffe ihr könnt mir helfen.
THX
Re: Debug Error
Verfasst: 28. Juni 2006 08:11
von Christian81
ConcordeLord hat geschrieben:
"File: ...qglaobal.cpp - QWidget: Must construct a QApplication before a QPaintDevice"
"Press Retry to debug the application"
Das sagt doch schon alles...
Man kann erst eine GUI-Operation (also aus QtGui) verwenden wenn ein QApplication-Objekt instanziiert wurde.
Verfasst: 28. Juni 2006 09:30
von ConcordeLord
Tja, soweit bin ich auch, nur das Problem ist, dass die Applikation vorher funktioniert hat. Jetzt habe ich eine Klasse zur Kommunikation eingefügt, die weder auf QPaintDevice oder ähnliches zugreift und seit dem tritt der Fehler auf.
Lösche ich die von mir erstellte Klasse wieder läuft wieder alles.
->Das ist das Problem!!!
Verfasst: 28. Juni 2006 09:35
von Christian81
Sie muss auf das QPaintdevice zugreifen da sonst der Fehler nicht käm.
Mach doch dort einfach einen Breakpoint und schau wo es herkommt.
Verfasst: 28. Juni 2006 12:26
von OscarWild
Christian81 hat geschrieben:Sie muss auf das QPaintdevice zugreifen da sonst der Fehler nicht käm.
Das wäre der simple Fehlerfall. Um den muss es sich hier aber nicht zwangsläufig handeln:
Ein immer wieder beliebtes C++ Problem lässt sich im Zusammenhang mit statisch modullokal instanzierten Objekten beobachten.
Man bedenke: die Reihenfolge der Instanzierung hängt dabei vom Linker und den Projektdateien ab. Wenn also ein Objekt das vorhandensein eines anderen erfordert (z.B. einer QApplication), dieses aber aufgrund der Linkerreihenfolge noch nicht an der Reihe war, erhält man damit recht bizarre Laufzeitfehler, die gelegentlich verschwinden oder wieder auftreten, wenn man an der Projektkonfiguration schraubt
@ConcordeLord: Bitte prüfe mal: sind irgendwo modullokal Objekte instanziert, die QPaintDevice benötigen?
Verfasst: 28. Juni 2006 13:07
von Christian81
So oder so - auf alle Fälle lässt es sich mit einem Breakpoint auf die Debug-Ausgabe leicht herausfinden...
Verfasst: 28. Juni 2006 13:25
von OscarWild
Christian81 hat geschrieben:So oder so - auf alle Fälle lässt es sich mit einem Breakpoint auf die Debug-Ausgabe leicht herausfinden...
Unterschätz das mal nicht. Der Fehler tritt in deisem Fall ggf. schon auf, bevor main() erreicht wird.
Verfasst: 28. Juni 2006 13:25
von Christian81
OscarWild hat geschrieben:Christian81 hat geschrieben:So oder so - auf alle Fälle lässt es sich mit einem Breakpoint auf die Debug-Ausgabe leicht herausfinden...
Unterschätz das mal nicht. Der Fehler tritt in deisem Fall ggf. schon auf, bevor main() erreicht wird.
Dann sieht man trotzdem im Backtrace wer der Verursacher ist, oder?
Verfasst: 28. Juni 2006 13:32
von OscarWild
Christian81 hat geschrieben:OscarWild hat geschrieben:Christian81 hat geschrieben:So oder so - auf alle Fälle lässt es sich mit einem Breakpoint auf die Debug-Ausgabe leicht herausfinden...
Unterschätz das mal nicht. Der Fehler tritt in deisem Fall ggf. schon auf, bevor main() erreicht wird.
Dann sieht man trotzdem im Backtrace wer der Verursacher ist, oder?
Möglicherweise, wenn man den Backtrace richtig interpretiert. Wer in die Falle mit den modullokalen Instanzen stolpert, wird vermutlich den Backtrace ebenfalls falsch interpretieren, bzw. sich noch mehr wundern.
Verfasst: 28. Juni 2006 13:33
von ConcordeLord
Klingt ja alles ziemlich plausibel, nur wo soll ich denn den Breakpoint setzen, wenn cih keine Ahnung hab, was oder wer den Fehler auslöst?
Verfasst: 28. Juni 2006 13:36
von OscarWild
ConcordeLord hat geschrieben:Klingt ja alles ziemlich plausibel, nur wo soll ich denn den Breakpoint setzen, wenn cih keine Ahnung hab, was oder wer den Fehler auslöst?
Vergiss den Breakpoint, schau erst mal Deine Quellcodes nach verdächtigen Kandidaten durch! Das Problem hast Du verstanden?
Verfasst: 28. Juni 2006 16:34
von ConcordeLord
Wenn ich jetzt noch wüßte, was modullokale Objekte sind, dann wär mir weitergeholfen. Hab aber schon wieder das nächste Problem.
Wollte heut eine klitzekleine Apllikation machen, nur zum Testen und der selbe Fehler tritt wieder auf.
Einfacher gesagt ich wollte das machen
http://qtforum.de/forum/viewtopic.php?t=2379
Nachdem ich die Sachen alle zusammengebaut hab und der Compiler keine Fehler mehr lieferte kam dann der selbe Fehler, wie bereits beschrieben. Ich bekomm langsam echt ne Krise. Hab den Tipp bekomm, dass ich doch alle Pointer, bevor ich sie verwendet abprüfen sollte. Hab das mit denen gemacht, die ich angelegt hatte, aber die beim Übersetzen vom uic angelegt werden, unterliegen diese auch dieser Prüfpflicht?
Weiß langsam echt nicht mehr weiter...
P.S.: Wird langsam eng, daran hängt nämlich meine Diplomarbeit...
Verfasst: 28. Juni 2006 17:00
von OscarWild
ConcordeLord hat geschrieben:Wenn ich jetzt noch wüßte, was modullokale Objekte sind, dann wär mir weitergeholfen.

Wenn Objekte nicht auf Funktions-, sondern auf Moduleben instanziert werden.
Beispiel: Gegeben sei ein Projekt, bestehend aus main.cpp, mod1.cpp und mod2.cpp:
main.cpp
Code: Alles auswählen
int main()
{
QApplication myApp; // funktionslokale Instanzierung von myApp
}
Modul1.cpp:
Code: Alles auswählen
QString hallo("Hallo"); // modullokale Instanzierung von hallo
Modul1Klasse::print hallo(int x)
{
QString welt("Welt!"); // funktionslokale Instanzierung von welt
}
Modul2.cpp:
Code: Alles auswählen
QPushButton press_me; // modullokale Instanzierung von press
Modul2Klasse::windwsSuxx()
{
...
}

die Instanz
press_me von QPushButton in Modul 2 ist Problematisch, da nicht sichergestellt ist, dass zum Zeitpunkt der Konstruktion bereits
myApp aus main.c existiert!
Verfasst: 28. Juni 2006 17:14
von Christian81
ConcordeLord hat geschrieben:Klingt ja alles ziemlich plausibel, nur wo soll ich denn den Breakpoint setzen, wenn cih keine Ahnung hab, was oder wer den Fehler auslöst?
Der Breakpoint muss an die Stelle, an der die Meldung ausgegeben wird -> also in den Sourcen suchen und man findet qwidget.cpp Zeile 90.
Und wenn Dein Testproggie das gleiche Verhalten zeigt - hänge es doch einfach mal an dann können wir es uns anschauen.
Verfasst: 29. Juni 2006 14:45
von ConcordeLord
So, hab die ganze Sache anders gelöst. Habe die von mir eingeführte Klasse aus der Applikation gelöscht, da ich doch n Denkfehler hatte.
Habe die Daten, die in dieser Klasse hinterlegt waren aufgeteilt auf die Forms bzw Widgets, die die Daten benötigen. ->Siehe da, es funktioniert wieder.
Das mit dem Testprogramm hab ich erstmal zurückgestellt. Falls ich dazu noch Fragen hab, werd ich es hier posten.
Ich dank euch trotzdem.