Beim Kompilieren auf Debug kommt immer F2084 Interner Fehler

[BastiFantasti]

Hallo zusammen,

ich bin am verzweifeln :roll:
ich habe auf einem neuen Windows 11 Rechner Delphi 11.3 installiert.
Danach via GetIt die gleichen Pakete wie auf meinem Hauptprogrammier PC installiert

Wenn ich jetzt ein Projekt öffne und auf Debug kompilieren möchte kommt immer der Fehler:

[dcc32 Fataler Fehler] F2084 Interner Fehler: DBG3603


leider werden keine weiteren Details ausgegeben.
Komischerweise kann ich das Projekt auf Release ohne Probleme kompilieren.

Auf dem Rechner eines Kollegen kompiliert sowohl die Debug als auch die Release Spezifikation des Projektes ohne Probleme.

Das "Internet" habe ich bereits durchforstet, bin aber auf keinen grünen Zweig gekommen. Die Meinungen dazu waren, dass das Problem nur per Trial and Error gefunden werden konnte...

Kennt jemand das Problem oder hat es sogar schon jemand lösen können :-D


UPDATE 1:
Nachdem das Kompilieren des Projektes mit dem internern Fehler abgebrochen wurde, lässt sich bis zum Delphi Neustart kein anderes Projekt mehr erfolgreich kompilieren. Hier werden dann unterschiedliche Fehler ausgegeben.
Z.B.

[dcc32 Fataler Fehler] F2084 Interner Fehler: AV5AF0C36D(5AE10000)-R43E66000-0

Viele Grüße
Bastian

[himitsu]

interne Fehler sind, wenn der Compiler selber ein Problem hat.

Lösung kann da nur der Hersteller bieten.
Diese Fehlercodes geben quasi die Stelle im Quellcode des Compilers an.


Was man machen kann:

* einmal Build statt Compile, bzw. einmal Clear

* und die IDE schließen und neu starten
* * der InlineCompiler kommt gerne in einen Zustand, ab wo er nicht mehr benutzbar ist ... daher ein Neustart

* man kann auch alternativ den InlineCompiler durch ein externes MSBuild ersetzen, weil das beendet sich nach jedem Kompilieren und wird somit immer neu gestartet
* * siehe Projektoptionen > Erzeugen > Delphi-Compiler
* * aber damit bekommt man andere Problemchen, z.B. müssen alle Dateien vorm Komplieren gespeichert werden

[TheFrog]

Ich hatte den selben Fehler bei Umstellung auf Delphi 11 (Windows 10) auch. Ich bin halb verzweifelt. Alle Tipps aus dem Internet (auch hier in der Delphi-Praxis) haben bei mir nicht geholfen.

Als ich Delphi 11.2 installiert hatte, war der Fehler scheinbar behoben (laut Info von Emba). Dieser ist dann auch seitdem nie wieder aufgetreten.

Ich hoffe doch, dass dieser mit Delphi 11.3 nicht wieder reingerutscht ist.

Bin gerade selber am überlegen, ob ich auf 11.3 umstelle, warte aber lieber noch etwas ab ;)

[jaenicke]

Kann es sein, dass der Unterschied zwischen Release und Debug der Schalter für Optimierung ist und es klappt, wenn du den umstellst?

Ansonsten:
Hast du einmal geschaut, ob es geht, wenn du in den Projekteinstellungen unter Kompilieren und Linken alles wie bei Release setzt?

[himitsu]

Wenn alles gleich eingestellt ist, dann ist es auch gleich.
Der Name ist vollkommen egal.



Auch ein {$IFDEF DEBUG} oder RELEASE} im Code reagiert nicht auf den Namen, sondern auf die "Bedingungen" in den Einstellungen.

[BastiFantasti]

Danke für die Rückmeldungen!

Ich habe vom Embarcadero Support die Info bekommen, dass es sich um ein Problem mit dem Aufruf einer "Function inside a Function" sein kann.
Diese Info hat leider auch nicht zur Lösung des Problems geführt.

Ich habe aus unserem Repo so lange ältere Stände ausgecheckt, bis ich einen lauffähigen Branch hatte.
Dann konnten wir das Problem einkreisen.

Es hängt zusammen mit einem Aufruf der OmniThreadLibrary.
Konkret verwenden wir die parallel.foreach Methode.
Diese verwenden wir allerdings schon länger und auch an mehreren Stellen im Code.
Aber diese eine Änderung hat das Problem erzeugt.

Wir haben fürs Debugging nun auf eine lineare Abarbeitung umgestellt und schon gehts.
Warum das allerdings ein Problem ist, oder warum es unter Delphi 11.0 noch funktioniert hat ist mir schleierhaft.

Viele Grüße
Bastian

[Uwe Raabe]

Kannst du das auf einen simplen Test Case runterbrechen und Primoz zukommen lassen?

[himitsu]

AV5AF0C36D(5AE10000)-R43E66000-0
sagt ja nur, wo der Fehler im Compiler auftritt,
daher deren Antwort.

Und nun kann es einfach sein, dass die OTL, in einem gewissen Modus ein Codestückchen in unpassender Art verwenden will, so dass es dort knallt.
Wobei auch vorhergehender Code einen Einfluß haben kann. Es kam schon vor, dass es einziges Leerzeichen/Leerzeile das Quentchen zum Überlaufen mitbrachte.

[BastiFantasti]

Das war die Antwort vom Embarcadero Support:

This is code in the compiler that displays that error:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
Symbol *GenLocalProcs()
...
invariant(procLineTab == 0 || procLineCur->varLocEntry == 0 ||
procLineCur->varLocEntry->h.proc == sym, "DBG");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
The problem occurs inside while the compiler is compiling these local procedures.


ich muss schauen, ob wir den Codeschnipsel in ein separates kleines Programm extrahieren können um es leichter nachvollziehen zu können.

[himitsu]

Beispiele für Fehler im Compiler sind meistens etwas zickig.

Ist das Projekt groß und man will/kann/darf nicht allen Code an Emba übergeben ...

• neues TestProjekt erstellen klappte selten (erfahrung Vieler), aber wenn, dann bist'e schnell fertig
   
   
• also aktuelles Projekt nehmen (neuer Branch) und dort so lange etwas entfernen, bis nur noch der Fehler übrig bleibt
  • also stückchenweise etwas entfernen/ersetzen, bis der Fehler weg ist
    zwischendurch auch die IDE ab und an mal neu starten (nicht dass sich IDE/Inlinecompiler was merken und die Änderung "jetzt" noch nicht sofort auffällt)
  • immer schön die Teilschritte committen
  • letzten Schritt wieder reverten/reseten
  • schauen ob es wieder knallt
  • den Teil lassen und das Nächste entfernen/ersetzen
  • weiter im Kreis, bis möglichst viel raus ist

Anstatt via QC (Jira) kann man auch einen "privaten" Support-Fall eröffnen (mit entsprechend teurer Lizenz sind eventuell ein paar kostenlose Support-Anfragen enthalten, ohne Extrakosten)