Debug Error

[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

[Christian81]

"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.

[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!!!

[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.

[OscarWild]

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?

[Christian81]

So oder so - auf alle Fälle lässt es sich mit einem Breakpoint auf die Debug-Ausgabe leicht herausfinden...

[OscarWild]

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.

[Christian81]

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?

[OscarWild]

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.

[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?

[OscarWild]

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?

[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...

[OscarWild]

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!

[Christian81]

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.

[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.