Seit Delphi 10.4 crasht mein Programm bei LoadPackage ohne verwertbaren Hinweis

[neubert]

Besten Dank für die Unterstützung.

Ich habe das so eingebaut und noch mehr: ich setze die Pfadangabe anfänglich auf C:\Windows\System32 und füge dann nur die Unterverzeichnisse mit den benötigten BPLs und DLLs in den richtigen zueinander passend kompilierten Versionen hinzu.

Ich kann dann alle meine Packages mit LoadPackage() laden bis auf mein Main-Package, welches als letztes drankommt. Der Debugger läuft noch bis zum Ende von InitUnits in System und dann gibt es eine AccessViolation mit leeren Aufruf-Stack bei Rückkehr aus InitUnits. Danach geht es nur noch mit AccessViolations weiter. Lasse ich das Main-Package in der LoadPackage()-Kaskade weg, läuft das Programm bis zum Ende durch.

InitUnits will 657 Units initialisieren (huch!), wobei im Main-Package in keiner Unit initialization-Sektionen drin sind.

Ich habe auch den Pfad überprüft sowie in den Environment-Einstellungen der IDE den Pfad mal sicherheitshalber geleert. Ich habe auch alle Stellen, wo Libraries liegen können, auf alte Libraries überprüft und nichts gefunden, was geladen werden könnte.

Fun Fact: nach einem solchen Crash ist auch der Compiler meist verwirrt und compiliert nicht mehr mit dieser Meldung:

Code:

[dcc32 Fataler Fehler] MeinProgramm.dpr(104): F2084 Interner Fehler: AV0A363340(0A340000)-R00000018-0

Interessanterweise läuft die Anwendung, wenn ich statt LoadPackage() die Main-Unit im Uses-Clause einbinde und die Main-Prozedur aufrufe.

Ich tendiere schon dazu, eine weitere virtuelle Maschine mit nichts außer Delphi 10.4 CE und den benötigten Libraries zu installieren, um sämtliche Einflüsse von Vorversionen und anderen Programmen auszuschließen. Aber ich glaube nicht so recht daran, dass es damit laufen wird.

[Delphi.Narium]

Dieses Verhalten sieht sehr schwer nach einem gravierenden Fehler in Deinem Main-Package aus, und zwar leider einer von der Sorte, die auch vom Compiler nicht als solcher erkannt werden.

Und dann bitte mal dashier +F2084 Interner Fehler durchforsten, etwas unter 100 Ergebnisse. Leider habe ich keinen Ahnung, welches davon für Dein konkretes Problem relevant sein könnte.

Ansonsten: Debuggen per Kommentar Will meinen:

In Deinem Package von allen Funtionen, Prozeduren den Inhalt (also alles zwischen dem ersten Begin und dem abschließenden end) auskommentieren.

Kompilieren und probieren, ob das klappt. Wenn nein, weiß ich nicht weiter

Wenn ja: Jeweils für genau eine Funktion / Prozedur die Kommentare entfernen. Dabei die Reihenfolge für den logischen Ablauf beachten. Jeweils ausprobieren und das solange wiederholen, bis das Problem wieder auftritt.

In der entsprechenden Routine muss irgendwas in "einem nicht wirklich korrekten Zustand" sein, ohne dass man jetzt definieren könnte, was eigentlich unter "einem einem nicht wirklich korrekten Zustand" genau zu verstehen ist

Und nein: Dieses Vorgehen sieht jetzt nicht wirklich hochprofessionell aus, hat mir in der Vergangenheit aber ab und an mal den Allerwertesten gerettet, wenn ein schier unlösbares Problem vorzuliegen schien.

[neubert]

Zitat von Delphi.Narium:

Ansonsten: Debuggen per Kommentar

Genau das werde ich tun. Aber andersherum: mit einem leeren Package starten und dann nach und nach die Formulare, Klassen und Methoden wieder reinnehmen bis es knallt oder läuft.

Alles sehr komisch, weil ja schon das Laden des Package zum Absturz führt, ohne dass (explizit von mir) überhaupt Code darin aufgerufen wird.

[Delphi.Narium]

Formulare im Package?

Die Formulare müssen ja dann wohl erstellt werden (einschließlich der darauf befindlichen Komponenten, ...) oder sollte das alles jeweils individuell zur Laufzeit passieren?

Eventuell nicht jedes mal "nur" neu kompilieren, sondern immer neu erstellen.

Gibt es innerhalb der Packages irgendwelche Abhängigkeiten zu weiteren Packages, ...

[neubert]

Ja, die Formulare werden alle erst zur Laufzeit erstellt, jeweils mit lokalen Variablen innerhalb der Methoden, aus denen sie aufgerufen werden. Ich eliminiere grundsätzlich alle globalen Formularvariablen in Formular-Units.

Die Abhängigkeiten glaube ich im Griff zu haben - es werden nur genau die Packages/Libraries geladen, die in meinen Lib-Unterverzeichnissen liegen, plus alles, was diese aus C:\Windows\System32 nachladen. Ich lasse das ganze auch ab und an in Linux unter Wine laufen - da fällt sofort auf, wenn eine Library fehlt.

Clean und Build statt Make sind schon die ganze Zeit meine besten Freunde :-/

[Delphi.Narium]

Einen hab' ich noch: F2084 Internal Error - %s%d (Delphi)

Eventuell könnte es sich um ein Speicherproblem, im Zusammenhang mit der IDE, handeln.

Mögliche Lösung: Nicht aus der IDE heraus kompilieren.

[CCRDude]

Wenn ich DLLs aus Unterverzeichnissen laden will (z.B. weil ich 32 und 64 bit executables im selben Ordner habe, die aber DLLS mit gleichem Namen nur anderer Bitness brauchen), aber den ladenden Code gar nicht anfassen will, mache ich das per Manifest.

Dort Einträge der Art <file name="meinelib.dll" loadFrom="subfolder/meinelib.dll">.

Wenn dort ein relativer Pfad steht, muss das Arbeitsverzeichnis der .exe stimmen, im Zweifel per chdir vor jedem anderen Ladevorgang.

SetDLLDirectory war mein Ansatz davor, der aber irgendwie hakte.

In diesem Fall geht es nur um diverse DLLs, aber Packages sind ja nichts anderes und werden vermutlich vom gleichen Lademechanismus verarbeitet?