Ich habe seit Tagen ein extrem merkwürdiges Problem mit meiner Anwendung. Da ich einfach nicht mehr weiter weiß habe ich mal den kompletten Code hoch geladen.

In 75% der Fälle läuft die Anwendung fehlerfrei. Aber in schätzungsweise 25% der Fälle stürzt die Anwendung beim Aufruf von glClear ab. Das ist komplett random. Manchmal ist es ein Segfault, manchmal ein abort-Aufruf. Vor einem Absturz friert jedes mal nahezu das komplette System für einige Sekunden ein. Manchmal hängt er sich auch dermaßen auf, dass ich das System reseten muss. (Stellt sicher das ihr alles gespeichert habt bevor ihr das probiert...) Das betreffende glClear findet sich in src/client/viewerwidget.cpp:219, was der Anfang meiner Render-Schleife ist.

Das ganze scheint irgendetwas mit meiner Mesh-Klasse zu tun zu haben. Wenn ich den Aufruf von m_mesh->set(...) in src/client/hovercraft.cpp:23 auskommentiere dann funktioniert alles wunderbar. Das merkwürdige ist, dass diese Mesh-Klasse in identischer Form in einem anderen Programm (meiner Diplomarbeit) fehlerfrei funktioniert.

Möglicherweise hängt das Problem mit einem Update des Grafiktreibers zusammen, allerdings funktioniert das Programm der Diplomarbeit weiterhin fehlerfrei. Ich habe den Grafiktreiber (nvidia) schon neu installiert, aber das hat auch nicht geholfen.


Es wäre schön wenn sich das mal jemand anschauen könnte. Hier das komplette Projekt:
(Download-Link nicht mehr verfügbar)


Es handelt sich um ein Qt-Projekt für Linux. Die Abhängigkeiten sollten sein:

• GLEW
• libpng
• Qt 4.6 oder neuer

Unter Linux sollte das ganze theoretisch wie folgt zu compilieren/starten sein:

Wenn das Programm läuft solltet ihr ein 3D-Terrain sowie ein dunkeles Dreieck sehen. Dieses Dreieck wird über die Mesh-Klasse gerendert. So siehts aus:


Achtung: Auf wenn die meisten Quellcode-Dateien einen GPL-Header haben, bitte ignoriert diesen!!! Ich habe für einige Teile des Quellcodes noch keine offizielle Freigabe. Diese Teile sind zwar von mir, gehören aber zur Diplomarbeit und damit dem Lehrstuhl. Eine Freigabe ist wahrscheinlich, aber wie gesagt noch nicht offiziell...also bitte setzt den Code vorerst nirgendwo in euren Projekten ein.

_________________
Yeah!

Hey,

das hört sich für mich nach nem Speicherproblem an. Manchmal hast einfach Glück und es klappt, und manchmal knallts irgendwo. Das es hängt, hört sich aber eher nach vielen speicher Alloziierungen an. Würd mal die Speicherauslastung und dmesg im Auge behalten.

Ansonsten mal CppCheck und Valgrind versucht? Die finden oft Fehler (erst recht Valgrind) die auf Speicherzugriffsverletzungen hindeuten, die man normal übersehen würde.

Hab den Code mal grob überflogen, konnte aber auf die Schnelle keine Fehler derart finden. Würd aber nochmal überprüfen, ob du alle Variablen (erst recht Pointer und Schleifengrenzen) anständig initialisierst.

Gruß
Shai

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

CppCheck kannte ich noch nicht. Hat ein paar Dinge gefunden, aber alles nur in Fehlerbehandlungscode der sowieso das Programm beenden soll. Valgrind werde ich heute Abend mal versuchen. Mit dem Tool hatte ich in der Vergangenheit aber bisher eher negative Erfahrungen da der Nvidia-Treiber sowieso voller (angeblicher?) Memory-Leaks ist.

_________________
Yeah!

Für den Treiber habe ich irgendwo ignorelists (Attached)… Weiß aber nicht mehr, ob die funktionieren (und schon garnicht, wie man die lädt ).

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also valgrind hilft mir auch nicht wirklich weiter. Habe unter anderem folgenden Aufruf benutzt:


Hauptsächlich findet er irgendwelche Fehler in Qt. Den einzigen Bug den ich gefunden habe war das der Destruktor vom QGLWidget nicht aufgerufen wurde. Das passiert nur am Ende...daher eigentlich völlig irrelevant. Waren noch ein paar andere ähnliche Sachen.

Allerdings findet er diverse Fehler dieser Art:

Das könnte was sein, hängt aber in /lib64/ld-2.13.so und hat somit was mit dem Linker zu tun. Findet sich ganz am Anfang der Ausgabe (siehe Anhang) Vielleicht ist da irgendwas falsch gelinkt?!

_________________
Yeah!

Zu dem Problem selber kann ich jetzt nix sagen. Schau mir das nochmal an wenn ich wieder zu Hause bin. Die "conditional" Meldungen von Valgrind im linker sollten nicht von bedeutung sein, siehe:
https://bugzilla.redhat.com/show_bug.cgi?id=676785

Dass er aber so viele leaks in X11 findet ist irgendwie krass. Und die restlichen QT Leaks scheinen irgendwas mit nem GTK Style zu tun haben. Leaks sind aber selten so gefährlich, dass sie ein Programm zum Absturz bringen. Das sollte eigentlich nur vorkommen, wenn sie den Speicher schon schön voll gemüllt haben und kein Speicher mehr zur Verfügung steht, was ich bei den paar KB mal ausschließe

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Der Valgrind Output ist in der Tat ziemlich harmlos, da nach den ersten paar ausgaben das Programm schon wieder beendet wurde (Heap Summary, alles danach sind ja nur leaks).

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich habe jetzt mal die Anwendung Schritt für Schritt komplett aus einander genommen bis nur noch ein Grundgerüst übrig war. Ein GIT-Repo ist dabei echt hilfreich, trotzdem ist es natürlich verdammt nervig wenn man die Maschine die ganze Zeit reseten und neu booten muss.

Aber das hat sich gelohnt, Fehler gefunden:
Die Methode QGLWidget::renderText(...) ist der Übeltäter, welche ich zum Anzeigen der FPS und einiger andere Infos benutzt habe.


Das Default-Setting ist natürlich QPaintEngine::OpenGL2. Eingeführt wurde der Spaß mit Qt 4.6, was erklärt warum meine FPS-Anzeige bei der letzten Verwendung in 2009 noch problemlos lief...das dürfte da nämlich noch Qt 4.5 gewesen sein. Soviel zur Zeitersparnis durch Wiederwendung von Code....quasi die Abende einer kompletten Woche verschwendet....

Thx @ alle Helfer

_________________
Yeah!