QApplication Deklaration führt zur Floating Point Exception

[GammaBlitz]

//...
int main(int argc, char *argv[]) {
cout << "main Mark 1" << endl << flush;
QApplication a (argc, argv);
cout << "main Mark 2" << endl << flush;
MainWindow w;
cout << "main Mark 3" << endl << flush;
w.show();
cout << "main Mark 4" << endl << flush;
return a.exec();
}

... führt nach dem Start zu folgender Ausgabe:
main Mark 1
Gleitkomma-Ausnahme

Ich bin ratlos und habe noch nichts dazu im Netz gefunden.
Die Deklaration von QApplication a führt zu einem
Signal SIGFPE: Floating-point exception (ANSI)

Starte ich die Anwendung im Debugger, funktioniert sie
problemlos.

Das Programm nutzt ein QGLWidget.

Ich habe es vorher problemlos kompilieren und starten können,
aber seit dem ich es vor ein paar Tagen neu kompiliert habe,
stürzt es ab. Am Code habe ich nichts geändert.
Wie bringe ich es zum Laufen? Kann mir einer einen Tipp geben?
Eine andere Qt-Anwendung von mir zeigt keine Macken.

Ich nutze Qt 4.6.3 auf Suse Linux 11.3.

[solarix]

Aufgrund des gezeigten Codes kann man da kaum Rückschlüsse ziehen... du hast folgende Möglichkeiten:

1. Setze "valgrind" ein.. damit hast du eine gute Chance

2. Reduziere den Code solange, bis der Fehler nicht mehr auftritt..

3. Reduzier das Projekt zu einer lauffähigen Demo und pack die Demo hier als Attachment rein..

hth!

[GammaBlitz]

Ich habe spaßeshalber mal die Qt-OpenGL Examples versucht zu starten.
Ergebnis: Alles stürzen mit einer Gleitkomma-Ausnahme ab.
Examples: /usr/lib/qt4/examples/opengl/
2dpainting,
framebufferobject
framebufferobject2
grabber
hellogl
overpainting
pbuffers
pbuffers2
samplebuffers
textures.
Alles stürzen ab. Es liegt also nicht an meinem Programm, sondern an Qt.
Speziell an den Qt-OpenGL-Programmen.
Ich habe den neuesten NVIDIA-Treiber mit Yast installiert, aber es hat sich nichts geändert. Jetzige Version: 260.19.21
Vorher hatte ich den NVIDIA-Treiber 260.19.12 installiert, da habe ich den Fehler bemerkt.

[Christian81]

Warum wird deshalb nochmal ein anderer Thread aufgemacht ( http://qtforum.de/forum/viewtopic.php?t=12819 )? Hast Du die Infos von Solarix ausprobiert?
Ich schätze da liegt noch irgendwo eine alte nvidia-lib rum...

[chrislo1976]

Hallo!

Es könnte ein generelles Problem mit dem Treiber bestehen!
Ich hab mir letzte Woche openSUSE 11.3 neu installiert, gleich danach die neuesten NVIDIA-Treiber.
Später hab ich erst bemerkt dass Amarok nicht funktionierte, sofort beim Starten abstürzte.

Nach längerer Suche im Internet bin ich auf eine Lösung gestoßen, damit Amarok wieder funktioniert: Einen älteren NVIDIA-Treiber installieren, z.B. den 256.53.

Probiers doch mal aus, evtl. hilft es auch bei deinem Programm.

Gruß,
Christian

[GammaBlitz]

An Solarix:

Wie gesagt, wird ein Qt-OpenGL-Programm, egal, ob mein eigenes, oder eines von den Qt-OpenGL-Examples von der Kommandozeile gestartet,
stürzt es ab.
Ich habe Valgrind installiert (danke für den Tipp!) und mein Programm damit gestartet. Im Debugger startet es. Ausgabe:

==6785== Command: machines01
==6785==
main Mark 1
main Mark 2
MainWindow () Mark 1
MainWindow () Mark 2
MainWindow () Mark 3
MainWindow () Mark 4
MainWindow () Mark 5
MainWindow () Mark 6
main Mark 3
==6785== Conditional jump or move depends on uninitialised value(s)
==6785== at 0x6950B10: ??? (in /usr/lib/libnvidia-glcore.so.260.19.21)
==6785==
==6785== Conditional jump or move depends on uninitialised value(s)
==6785== at 0x6950B19: ??? (in /usr/lib/libnvidia-glcore.so.260.19.21)
==6785==
==6785== Use of uninitialised value of size 4
==6785== at 0x6950B22: ??? (in /usr/lib/libnvidia-glcore.so.260.19.21)
==6785==
main Mark 4
==6785== Conditional jump or move depends on uninitialised value(s)
==6785== at 0x4495BAE: QTransform::fromScale(double, double) (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x43BB8C3: QPixmap::scaled(QSize const&, Qt::AspectRatioMode, Qt::TransformationMode) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x438A92D: ??? (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x4388353: QIcon::pixmap(QSize const&, QIcon::Mode, QIcon::State) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x460EB04: QCommonStyle::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x46C5247: QWindowsStyle::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x46AE35F: QCleanlooksStyle::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x4616DBA: QCommonStyle::drawComplexControl(QStyle::ComplexControl, QStyleOptionComplex const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x46CB874: QWindowsStyle::drawComplexControl(QStyle::ComplexControl, QStyleOptionComplex const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x46B55DA: QCleanlooksStyle::drawComplexControl(QStyle::ComplexControl, QStyleOptionComplex const*, QPainter*, QWidget const*) const (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x47B2B62: QToolButton::paintEvent(QPaintEvent*) (in /usr/lib/libQtGui.so.4.6.3)
==6785== by 0x432EF59: QWidget::event(QEvent*) (in /usr/lib/libQtGui.so.4.6.3)
==6785==

Es scheint also etwas mit der Library libnvidia-glcore.so.260.19.21 und
mit /usr/lib/libQtGui.so.4.6.3 nicht zu stimmen.
Ich habe auch mal hellogl von den Examples neu kompiliert. Das gleiche
Verhalten. In der Kommandozeile direkt gestartet stürzt es ab, mit Valgrind debugt läuft es. Allerdings zeigt der Debugger hier gar keine Fehler an. Weil auch hellogl nicht funktioniert, halte ich es nicht für sinnvoll, extra für die Fehlersuche noch ein Qt-OpenGL-Programm zu schreiben. Man kann sich an hellogl halten.


An Christian81:

Ich kam auf den Gedanken, dass es weniger ein Programmierproblem, sondern eher ein Library-Problem ist und hatte deshalb einen Thread im allgemeinerem Forum erzeugt.

An chrislo1976:

Ich habe mal mit ldd <programmname> die geladenen Libraries angesehen und festgestellt, dass von den NVIDIA-Libraries ausschließlich die richtigen Versionen geladen werden.
Ich möchte lieber nicht auf einen älteren Treiber wechseln, obwohl das ein guter Tipp ist, weil der nicht mit Yast installiert werden müsste, sondern auf der Kommandozeile. Und jetzt habe ich schon die ganzen Kernel-Packete, usw. von 260.19.21 installiert, da befürchte ich einen einen ziemlichen Datensalat, wenn ich da einen älteren Treiber per Hand darüber installieren würde.

Grundsätzlich funktioniert OpenGL ja einwandfrei (Bildschirmschoner, Doom3), eben nur nicht mit Qt-OpenGL.

[Christian81]

Bei mir funktioniert es mit dem aktuellen NVidia-Treiber und Qt 4.7 unter 11.3. Denke auch dass es mit 4.6 bei uns auf Arbeit funktioniert. Aber wir benutzen immer den Oxygen-Style (qtconfig zum Umstellen).
Du kannst auch mal die Qt4-Debuglibs installieren (Erst repo aktivieren, dann nach libqt4-debuginfo suchen). Ggf. auch debugsources - dann sieht man genau wo in QTransform es abstürtzt.

[GammaBlitz]

An Christian81:

Ich habe den Oxygen-Style aktiviert und die Debug-Libraries installiert.

valgrind -Ausgabe bei meinem Programm:
...
==11969== Conditional jump or move depends on uninitialised value(s)
==11969== at 0x4495BAE: QTransform::fromScale(double, double) (qtransform.cpp:505)
==11969== by 0x43BB8C3: QPixmap::scaled(QSize const&, Qt::AspectRatioMode, Qt::TransformationMode) const (qpixmap.cpp:1440)
==11969== by 0x438A92D: QPixmapIconEngine::pixmap(QSize const&, QIcon::Mode, QIcon::State) (qicon.cpp:289)
==11969== by 0x4388353: QIcon::pixmap(QSize const&, QIcon::Mode, QIcon::State) const (qicon.cpp:678)
==11969== by 0x460EB04: QCommonStyle::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const (qcommonstyle.cpp:1597)
==11969== by 0x7C7949E: KStyle::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const (in /usr/lib/libkdeui.so.5.4.0)
==11969== by 0x8D3D781: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==11969== by 0x7C804EF: KStyle::drawComplexControl(QStyle::ComplexControl, QStyleOptionComplex const*, QPainter*, QWidget const*) const (in /usr/lib/libkdeui.so.5.4.0)
==11969== by 0x8D3A6CB: ??? (in /usr/lib/kde4/plugins/styles/oxygen.so)
==11969== by 0x47B2B62: QToolButton::paintEvent(QPaintEvent*) (qstylepainter.h:94)
==11969== by 0x432EF59: QWidget::event(QEvent*) (qwidget.cpp:8190)
==11969== by 0x46DD7CF: QAbstractButton::event(QEvent*) (qabstractbutton.cpp:1080)

valgrind-Ausgabe bei hellogl:

...

==11544== Conditional jump or move depends on uninitialised value(s)
==11544== at 0x4400532: PtsToRegion(int, int, _POINTBLOCK*, QRegionPrivate*) (qregion.cpp:3527)
==11544== by 0x4400FE8: PolygonRegion(QPoint const*, int, int) (qregion.cpp:3750)
==11544== by 0x44013A0: QRegion::QRegion(QPolygon const&, Qt::FillRule) (qregion.cpp:3871)
==11544== by 0x446D9E9: QX11PaintEngine::updateState(QPaintEngineState const&) (qpaintengine_x11.cpp:1087)
==11544== by 0x43AD370: QPainterPrivate::updateStateImpl(QPainterState*) (qpainter.cpp:893)
==11544== by 0x43AD441: QPainterPrivate::updateState(QPainterState*) (qpainter.cpp:921)
==11544== by 0x43B0A71: QPainter::setClipRegion(QRegion const&, Qt::ClipOperation) (qpainter.cpp:2839)
==11544== by 0x42A026A: QWidgetPrivate::paintBackground(QPainter*, QRegion const&, int) const (qwidget.cpp:2221)
==11544== by 0x42A413C: QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) (qwidget.cpp:5341)
==11544== by 0x4481A97: QWidgetBackingStore::sync() (qbackingstore.cpp:1300)
==11544== by 0x42996FA: QWidgetPrivate::syncBackingStore() (qwidget.cpp:1688)
==11544== by 0x42A9A15: QWidget::event(QEvent*) (qwidget.cpp:8337)
==11544==
==11544== Conditional jump or move depends on uninitialised value(s)
==11544== at 0x4400532: PtsToRegion(int, int, _POINTBLOCK*, QRegionPrivate*) (qregion.cpp:3527)
==11544== by 0x4400FE8: PolygonRegion(QPoint const*, int, int) (qregion.cpp:3750)
==11544== by 0x44013A0: QRegion::QRegion(QPolygon const&, Qt::FillRule) (qregion.cpp:3871)
==11544== by 0x446DD03: QX11PaintEngine::updateState(QPaintEngineState const&) (qpaintengine_x11.cpp:1105)
==11544== by 0x43AD370: QPainterPrivate::updateStateImpl(QPainterState*) (qpainter.cpp:893)
==11544== by 0x43AD441: QPainterPrivate::updateState(QPainterState*) (qpainter.cpp:921)
==11544== by 0x43B0A71: QPainter::setClipRegion(QRegion const&, Qt::ClipOperation) (qpainter.cpp:2839)
==11544== by 0x42A026A: QWidgetPrivate::paintBackground(QPainter*, QRegion const&, int) const (qwidget.cpp:2221)
==11544== by 0x42A413C: QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) (qwidget.cpp:5341)
==11544== by 0x4481A97: QWidgetBackingStore::sync() (qbackingstore.cpp:1300)
==11544== by 0x42996FA: QWidgetPrivate::syncBackingStore() (qwidget.cpp:1688)
==11544== by 0x42A9A15: QWidget::event(QEvent*) (qwidget.cpp:8337)
...

Da scheint es an verschiedenen Stellen Fehler zu geben.

[Christian81]

Das ist aber nicht die Stelle an der das Proramm crasht auch wenn da wohl ein kleines Problem in qtransform.cpp ist.

[GammaBlitz]

Ich habe nun doch den Rat von chrislo1976 befolgt und NVIDA-Treiber 256.53 installiert.
Jetzt gibt es keine Probleme mehr. OpenGL funktioniert nun auch mit Qt-Programmen. Auch alle anderen OpenGL-Programme funktionieren.

Trotzdem habe ich mal mein Qt-OpenGL -Programm mit valgrind debugt und es zeigt nach wie vor die selben Fehler an. Kein Unterschied.

Danke für die Hilfe.

[solarix]

Spannend.. werde ich mir merken (ich hatte noch nie Probleme mit den NVIDIA-Treibern)..

Auf meinem aktuellen Arbeitsgerät liefert mit valgrind beim hellogl dafür 100'000e "Invalide write"s in /usr/lib/fglrx/dri/fglrx_dri.so (ATI/AMD-Driver).
Proprietäre Treiber sind doch ein Segen

Wegen "QTransform::fromScale": Das ist eigentlich nie der Übeltäter sondern eher das Opfer im Sinne "den letzten beißen die Hunde". Wenn irgend eine aufrufende Instanz im Stack des "paintEvent()" uninitialisierte Variabeln besitzt, werden die häufig erst in QTransform aufgedeckt.

Im Übrigen: die gezeigten Stacks habe ich bei eigenen Analysen noch nie gesehen. Wie Christian bin ich auch der Meinung, dass das vermutlich mit den eingesetzten Styles zusammenhängt (KStyle.. KDE?)... (ich kenne KDE nicht.. wir verwenden GNOME, fluxbox und lxde).

hth..

[franzf]

Auf meinem aktuellen Arbeitsgerät liefert mit valgrind beim hellogl dafür 100'000e "Invalide write"s in /usr/lib/fglrx/dri/fglrx_dri.so (ATI/AMD-Driver).
Proprietäre Treiber sind doch ein Segen

Ich hab mit Nvidia-Drivers immer wieder Probleme auf ner GT220 und GT6600 (spontane SegFaults, X 100%CPU, etc). Bin auf meiner Kiste (die 6600er) Vorgestern auf nouveau+Gallium3D. Was bin ich froh! Ist zwar noch etwas experimentell, aber es funktioniert! Für ausgibige Tests ist es natürlich zu kurz, aber bisher ist bei meinen üblichen Arbeitsabläufen nix passiert.