Benedikt: C++, SDL, OpenGL: Problem mit SDL_Quit()

Beitrag lesen

Gegen Debug-Versionen linken und IN den Aufruf "steppen"!

Ich habe den SDL_Quit bis zum letzten Aufruf Zeile für Zeile zerlegt. Nichts. Das Programm beendete sich bei jedem Debug versuch einwandfrei.
 Da finde ich nichts was mir bei der Lösung hilft.
 Und wenn ich was finde, das ist alles SDL intern, da müsste ich ja in der SDL den Fehler ausmerzen. Aber das will ich nicht.
Ich gehe stupide davon aus das alle Fremd-Libs absolut Fehlerfrei sind. Der Fehler befindet sich immer beim User also bei mir im Programm.

Der läuft die SDL_Quit sogar zweimal durch und die TTF_Quit auch.
zum einen weil es in meiner exit() Funktion drinsteht zum andern weil es bei atexit() eingetragen ist. Und wenn er beim ersten Durchlauf keinen Fehler macht aber beim 2. Durchlauf dann muss das SDL intern sein.
Und das schließe ich durch meine Annahme aus. SDL* = Bugfrei.
Und selbst wenn kann ich mir nicht vorstellen das grad ich einen Bug bei der SDL finde. Der Bug muss in meinem Code sein aber wo?
Ich habe jetzt sogar nur mal die Init Funktion und die Exit Funktion in eine eigenes Programm gepackt. Also keinen Code außenrum, außer die Log-Funktionalität. Das Problem tritt genauso wieder auf.
Es wird auch nichts gerendert, aber die Events werden verarbeitet.
Wie davor auch kann es sein das sich das Programm 4 mal hintereinander einwandfrei beendet und beim 5. mal alles zerschiesst.

Klingt jetzt blöd. Aber das passiert jetzt nicht jedesmal. Es kann jetzt auch sein das sich das Programm so beendet wie es soll und der XServer bleibt ganz. Also mit dem Debugger bin ich bis jetzt noch nich weitergekommen. Debugger brachte noch keine Ergebnis.

Das klingt schon zweimal nach einem Deallocationsproblem.

Also: Debuggen!

Wie gesagt ich finde leider nichts in der Richtung.

  1. Wieviele Threads hat das Programm?

Ich habe die anderen Threads auch schon alle abgeschalten. Also nur mit einem laufen lassen. Das ändert gar nix. Also 1 Thread hat das Programm.

Glaub ich noch nicht.

Dass Du selbst keine eigenen Threads erzeugst ist kein hinreichendes Kriterium; wie hast Du z.B. ermittelt, dass die Bibliotheken keine eigenen Threads erzeugen; etwa für die Oberfläche?

Das kann ich mir sehr schwer vorstellen.

  1. Solche "Spaghetti"
    [...]
    machen den code nicht gerade wartungsfreundlich; es gibt Arrays, Schleifen etc. und falls Du C++ verwendest auch noch vector, map, iterator....

Das ist zwar lieb gemeint,

Das ist weder lieb noch böse gemeint, sondern ist ein Hinweis zur Verbesserung Deines Programmierstils.

aber bringt mir nicht wirklich was.

Die Logik dieser Aussage solltest Du einmal selbst hinterfragen.

Willst du jetzt wegen solcher Lapalien mit mir einen Streit anzetteln?
Das was du hier kritisierst ist eher ein Stilbruch, aber dieses Stück Code tut seinen Dienst. Man kann das ja dann immer noch wegoptimieren mit Arrays und Schleifen wie du schon so schön sagtest.
Aber dennoch bringt es mir nichts wenn du sagst das ich das anders schöner schreiben kann.
Die Funktion dieses Stück Codes wäre immer noch die gleiche.
Es würden immer noch 8 mal ein Font geöffnet mit verschiedenen Größen und irgendwo gespeichert.
Ob das nun in einem Array ist oder in 8 verschiedenen selbstständigen Variablen ist doch für mein Problem völlig Egal.

Ich habe da auch noch eine schwache Verteidigung. Es gibt viele Beispiele im Internet (verschiedene Tutorials, teilweise findet man auch mit Google labs) oder verschiedene Bücher.
Dort finden sich oft solche Beispiele.
Es ist halt auch immer eine Geschmacksfrage.
Der eine findet 8 Variablen besser und der andere ein Array mit 8 Elementen. Aber im Endeffekt bewirken beide dasselbe. Die Daten sage ich jetzt mal sind nur anders organisiert.

Aber ich wäre dir sehr verbunden wenn wir unser Augenmerk auf mein tatsächliches Problem richten könnten.

Benedikt