Hallo,

ich erhalte bei jeder Anwendung mit dglopengl einen Laufzeitfehler. Grundsätzlich immer beim beenden dieser. Dazu muss auch gar nichts groß drin sein, es reicht bereits nur einen Kontext erstellt zu haben:



ActivateRenderingContext ist nicht nötig. CreateRenderingContext ist hier das Problem.
Das betrifft auch die ganzen Beispieldateien, die man hier herunterladen kann, sowie diverse

Das meiste läuft allerdings zunächst normal. Erst beim Beenden der Anwendung kommt es zum Laufzeitfehler:

Manuelles "destroyrenderingcontext" oder schließen des Fensters zu dem der Kontext gehört bewirkt keinen Fehler. Nur das beenden der gesamten Anwendung.

Mit Delphis eigener OpenGL-Library tritt das nicht auf.

Ich benutze gerade das gute alte Delphi 7 mit der aktuellsten dglopengl, die auch hier auf der Seite verlinkt ist ("OpenGL 4.5 - Headertranslation").

Ich habe schon alles mögliche probiert, aber ich weiß nicht, was ich noch tun kann. Jemand eine Idee? Danke!

Hi,

"feeefeee" wird durch Microsofts Speicher-Verwaltung gesetzt und bedeutet das ein Block freigegeben wurde. Vermutlich gibt es also bei Delphi 7 irgendein Problem mit dem Lebenszyklus einer Komponente. Diese wird freigegeben bevor man es mitbekommt und schon knallt es. Normalerweise sollte dein Debugger dir anzeigen welche Variable das betrifft oder einen Callstack liefern. Frag mich jetzt aber nicht wie das bei Delphi funktioniert

_________________
Meine Homepage

InitOpenGL ?

InitOpenGL wird hier in der If-Anweisung aufgerufen:


https://wiki.delphigl.com/index.php/Tutorial_Quickstart

Tritt leider auch mit InitOpenGL auf. Hatte das nur im Zuge der Fehlersuche entfernt um den auslösenden Befehl einzugrenzen.



Hat also das gleiche Ergebnis. Es läuft erstmal alles normal, aber beim Beenden der Application tritt der Laufzeitfehler auf.
Eine Variable oder Codestelle wird mir nicht angezeigt, nur die CPU-Ansicht. Bei F7 kommt man als nächstes auf "mov ebx, [esp]" was wahrscheinlich kein bisschen weiterhilft.
Hoffte zuerst, es wäre irgendwas lokales bei mir, aber es tritt auch auf fremden Rechnern auf, wenn man dort die exe ausführt. Allerdings anscheinend nicht immer. Mit Wine unter Linux gibt es ebenfalls am Ende einen Fehler aus, aber ohne Informationen.


edit: Die CPU-Ausgabe ist vielleicht doch hilfreich. Dort erscheint weiter oben "call ntdll.RtlReleaseActivationContext" und weiter unten "ntdll.RtlUnwind:". Es ist daher anzunehmen, dass der Assemblerkram dazwischen auch damit (ntdll) zusammenhängt. Was mir allerdings nichts sagt.

edit2: Geht mit F7 noch eine Weile weiter kommt neben der Wiederholung noch "application-defined exception (code 0xc000001d) at (0x7ffe0307)". Könnte aber nur eine Folge des ursprünglichen Fehlers sein. edit3: Das kann man wohl ignorieren und liegt nur am fehlenden "destroyrenderingcontext". Der ursprüngliche Laufzeitfehler bleibt aber. Bei compilierten Anwendungen außerhalb der Delphi IDE kommt es nicht immer zu einem Fehler. Weird.

Wird vllt noch eine 2.Instanz des Programms aufgemacht? So dass die eine Instanz der anderen den Context destroyed.

RTLUnwind ist eigentlich das Exception unwinding, also wenn ne exception geworfen wird, dann reicht der Kernel die in die Applikation an den Programm Cursor und geht dann rückwärts bis zum Kernel. Wenn deine Applikation ned unterwegs diese behandelt bekommt man ein Error Fenster mit der Exception vom Fenster Manager und im Kernel wird dann auch ein Logeintrag im Systemlog gemacht.
Sobald die Exception verarbeitet wird, ob von deiner App oder vom Kernel wird ein stack unwinding gestartet, damit alle Resourcen wieder freigegeben werden, die auf dem Weg zur Exception generiert wurden.
Für RAII tut der compiler in der Regel code generieren und für den dynamischen kram hat man den catch block und muss es per hand machen bzw. je nach sprache der Garbage Collector.

CreateRenderingContext erzeugt eine Ressource, die gleich an mehreren Stellen die AV auslösen könnte.
Wenn du z.B. in einem Fenster Event die Ressource benutzt aber schon eine zerstörung des Fensters durch schliessen veranlasst hast.
Der klassiker wäre in WM_PAINT -> OnPaint die zu nutzen und beim schliessen knallt es, weil WM_DESTROY von einem WM_PAINT gefolgt passieren kann und damit der Context schon aufgeräumt ist.

Multithreading ist der nächste Kandidat, z.B. ein Zugriff vom Thread aus und der Kontext wurde schon abgeräumt.
Threads werden erst nach den Fenstern abgeräumt.

Je nach Treiber kann es auch reichen RC auf einem Thread zu verwenden und ohne ActivateRenderingContext vorher im Thread auf zu rufen, ist die Resource invalide und sollte auch eine Exception oder Error generieren.
NV Treiber erkennen z.B. ob man den Context von einem anderen Thread aus nutzt und tun im Hintergrund umschalten, während AMD sich an die Specs hält und ein Fehler wirft.
Wenn man dann mit CodeXL mal OpenGL Applikationen debugged, dann bekommt man graue Harre, was OpenGL Entwickler mit NV Karten alles so falsch machen und das auf kosten von Performance, weil der Treiber es dann intern extra behandeln muss.

Es ist ratsam auch mal zu gucken ob die Ressource überhaupt korrekt erstellt wurde.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo,

danke für die ausführlichen Antworten, sehr interessant.

Eine weitere Instanz ist nicht offen und der Kontext ist vollständig erstellt (zumindest funktioniert alles).

Ich kam nun auf die Idee, eine neue virtuelle Maschine (darin läuft XP nämlich) mit den gleichen Parametern zu erstellen und Delphi neu zu installieren. Und da tritt der Fehler nicht auf (lade exakt die gleichen Dateien)

Es scheint also etwas mit Delphi zu tun zu haben. Möglicherweise eine der Komponenten, die dort installiert sind? Allerdings nutze ich bei dem ganz einfachen Test keine. Daher wird mir nicht klar, wie sie die IDE und vor allem den Compiler beeinflussen könnten. Der Unterschied nun sind vor allem die fehlenden Jedi-Komponenten und auch eine eigene (welche OpenGL nutzt). Letztere hatte ich bereits zum Test mal aus der IDE entfernt. Interessant ist, dass Programme, die sie nutzen weiterhin Laufzeitfehler beim beenden aufwerfen, wenn auch andere ("control has no parent window"). Ob das zusammenhängt weiß ich nicht.

Der einfache Test funktioniert nun auf jeden Fall unter der anderen Delphiinstallation...

Warum nutzt du überhaupt noch das alte D7?
Lazarus kann mehr als das alte Teil und falls du nicht soviel konfigurieren willst, nehm CodeTyphon.
Bin sogar von D2007 und D2010 umgestiegen und viel glücklicher damit nu.

Ich glaube, es gibt sogar die neuste oder zweitneuste Delphi-Version als Starter (immer noch) kostenlos.

Nun so ziemlich jede höhere Toolchain zaubert dir zusätzlichen Code aus den jeweiligen Standard- und Laufzeitbibliotheken rein. Die Frage ist halt immer nur was die Politik des jeweiligen Herstellers dabei genau zur Folge hat.

_________________
Meine Homepage

Wieso CodeTyphon, die Standard-Version von Lazarus ist schon gut vorkonfiguriert.



Das ist mir nicht bekannt.

_________________
OpenGL

Habe gelesen, es geht noch. Die Webseite sieht aus so aus.
https://www.embarcadero.com/de/products ... l-download