Delphi meldet sinnlose Compilerfehler

[Carsten Hölscher]

Auch mit der letzten Delphi-Version hab ich folgenden Effekt mit gefühlt in letzter Zeit zunehemender Häufigkeit:
Mein Projekt kompiliert nur noch zufällig erfolgreich, mal geht es, mal nicht in erratischer Weise teils mit unverändertem Quellcode.
Eben gerade war es so, dass 64bit release und debug swieso 32bit release liefen, während 32 bit debug folgende Beschwerden lieferte:

Code:

[dcc32 Fehler] ZusiNetzwerkForm.pas(1114): E2003 Undeklarierter Bezeichner: 'TZugfernsteuerungProzess'
[dcc32 Fehler] ZusiNetzwerkForm.pas(1114): E2066 Operator oder Semikolon fehlt
[dcc32 Fehler] ZusiNetzwerkForm.pas(1116): E2382 Konstruktoren können mit Instanzenvariablen nicht aufgerufen werden
[dcc32 Fehler] FehlersucheForm.pas(108): E2003 Undeklarierter Bezeichner: 'TZusi3Grafik'
[dcc32 Fehler] FehlersucheForm.pas(309): E2066 Operator oder Semikolon fehlt
[dcc32 Fehler] FehlersucheForm.pas(309): E2066 Operator oder Semikolon fehlt
[dcc32 Fehler] FehlersucheForm.pas(352): E2066 Operator oder Semikolon fehlt
[dcc32 Fehler] FehlersucheForm.pas(352): E2066 Operator oder Semikolon fehlt
[dcc32 Fataler Fehler] F2063 Verwendete Unit 'FehlersucheForm.pas' kann nicht compiliert werden

Wenn man sich die Stellen im code anschaut, sind die alle i.o., sie laufen ja auch in den anderen 3 Versionen durch.
Hat jemand eine Idee, wie man sich dem Problem nähern kann?
Wenn ich jetzt irgendwas an anderer Stelle umprogrammiere, dann kann es danach möglicherweise wieder laufen, es ist völlig erratisch aber sehr lästig.
Manchmal hilft auch Strg-F9, wenn man Glück hat, ändert sich die bemängelte Stelle zunächst von Aufruf zu Aufruf und am Ende läuft es durch. Aktuell bekomme ich es gerade in 32bit debug gar nicht ans Laufen....

Carsten

[Uwe Raabe]

Zitat von Carsten Hölscher:

Eben gerade war es so, dass 64bit release und debug swieso 32bit release liefen, während 32 bit debug folgende Beschwerden lieferte:

Das ist so ohne weitere Informationen nicht effizient zu analysieren. Es kann z.B. an bestimmten IFDEFs liegen, die ein unterschiedliches Verhalten hervorrufen. Auch abweichende Einstellungen in den Konfigurationen sind als Ursache möglich.

Ich will nicht ausschließen, dass der Compiler in gewissem Maße non-deterministic ist, aber in diesem Fall würde ich das Problem zunächst an anderer Stelle suchen.

[Sinspin]

Was passiert wenn du zweimal hintereinander kompilierst ohne etwas zu verändern? Beim zweiten mal läuft es bei mir meißt durch.

Probier auch mal die ganzen Entwicklerverzeichnisse von deinem Antivirus Live Scan auszuschließen. Es muss nicht immer an Delphi liegen

[himitsu]

Zitat:

zweimal

Ändert wohl nichts, aber vielleicht einmal Build oder vorher Clean, anstatt nur Compile.


Beim Inline-Compiler hilft es auch manchmal Delphi neu zu starten,
oder auf externes Kompilieren (msbuild) umzustellen.
(hier aber vor allem wenn man vom Internal Error geplagt wird und danach dann eh nichts mehr geht)

[Carsten Hölscher]

Als ich das jetzt mal testen wollte, lief wieder alles korrekt. Was ich aber vorher geändert hatte:
Ich nutze reichlich Kompilerdirektiven, da ich aus meinen Code etliche Varianten je nach Version/Kundenkreis produzieren kann. Eine länger nicht mehr benutzte Variante warf berechtigte Fehler, da die Kompilerdirektiven für diese Variante zu Doppeleinträgen in der uses-Klausel führten.
Diese Fehler habe behoben. Danach lief auch die zuvor problematische Version wieder, die von diesem Kompilerdirektiven-Fehler nicht betroffen war. Kann es sein, dass sowas die Ursache für das Problem ist und dann Unsinn an völlig anderen Zeilen gemeldet wird?

Carsten

[himitsu]

Geänderten Quelltext erkennt der Compiler normalerweise und erzeugt die jeweiligen DCUs neu, auch bei einem einfachen Compile.

Aber vor allem DEFINE aus INC oder via Parameter oder Projektoptionen betrifft das nicht, da die Genutzen scheinbar nicht in der DCU nicht stehen (oder es nicht geprüft wird).



Egal, es bleibt wie schon gesagt.

Zitat:

Ändert wohl nichts, aber vielleicht einmal Build oder vorher Clean, anstatt nur Compile.

[Carsten Hölscher]

Danke fürs Augenöffnen mit Strg-F9 und Shift-F9, das hatte ich doch glatt falsch im Kopf.
Was genau ist denn ein "Clean"?

Gestern dann mal eine neue Spielart, nachdem ich alle exe des Projekts in diversen Compilerschaltervarianten getestet und ggf. korrigiert hatte: Es kompiliert alles aber beim Start kommt es zu einem Fehler in der folgenden Art:

Code:

---------------------------
Benachrichtigung über Debugger-Problem
---------------------------
In Projekt D:\.........exe trat ein Problem mit folgender Meldung auf: 'system exception (code 0xc000041d) at 0x33eee275'. Prozess angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK   
---------------------------

Der Fehler wird in der dpr-Datei ausgelöst, wenn man ein Formular erzeugt, noch bevor das oncreate des Forms angesteuert wird. Das Formular ist völlig harmlos, nur ein paar Eingabefelder und OK-Buton.

Aber dann hab ich mal alle Debugger-Haltepunkte gelöscht (waren glauch ich gar nicht aktiv) und seitdem läuft alles einwandfrei. Vielleicht hilft das ja mal anderen Lesern...

Carsten

[himitsu]

Hier wird aber nicht zufällig mit einem Windows-Dienst/Service rumgespielt?

Zitat:

0xc000041d

41d = ERROR_SERVICE_REQUEST_TIMEOUT
https://learn.microsoft.com/en-us/wi...es--1000-1299-

[ConnorMcLeod]

Zitat von Carsten Hölscher:

Was genau ist denn ein "Clean"?

Ungefähr sowas (das macht bei mir ein Batchfile, das im "Tools"-Menüpunkt hinterlegt ist:

Code:

del *.dcu /s
del *.exe /s
del *.map /s

[Carsten Hölscher]

OK, das entspricht ca. meiner Erwartung.

Zitat:

Hier wird aber nicht zufällig mit einem Windows-Dienst/Service rumgespielt?

Bin mir keiner Dinge bewusst in der Hinsicht. Was bzw. welche Komponenten könnte das denn auslösen? Als der Fehlerfall anlag, bin im Debugger die dpr-Datei schrittweise duchgegangen und bei Create jenes banalen Forms kam reproduzierbar der Fehler.

Carsten