Seit Delphi 10.4 crasht mein Programm bei LoadPackage ohne verwertbaren Hinweis

[neubert]

Hallo,

ich habe ein Programm mit etwa 20 Runtime-Packages und einer Reihe von Packages von Embarcadero (resdistributables) und von Drittanbietern. Die .bpl- und teils .dll-Dateien habe ich in Unterverzeichnissen zur .exe-Datei abgelegt. Die .exe-Datei beinhaltet einen Bootstrapping-Mechanismus, der die Libraries der Reihenfolge nach lädt und dann aus dem Main-Package das eigentliche Hauptprogramm (VCL-Applikation) startet. Gründe: 1) Ich mag die Bibliotheken gerne fein säuberlich getrennt in individuellen Unterverzeichnissen (meine, Embardcadero, Drittanbieter). 2) Ich will steuern, welche Packages in welcher Reihenfolge geladen werden, um zu verhindern, dass versehentlich irgendwo anders liegende alte Versionen automatisch geladen werden, und um zu sehen, ob die Abhängigkeitsstrukturen innerhalb der Package-Familie stimmen.

Das lief wunderbar bis Delphi 10.3.3 CE. Nun versuche ich auf Delphi 10.4 CE umzusteigen. Zunächst waren kleinere Änderungen im Code erforderlich, weil sich Signaturen geändert haben oder der Compiler pingeliger ist. Danach ließ sich das Gesamtwerk compilieren.

Allerdings crasht nun schon der Bootstrapping-Ablauf irgendwo, ohne dass der Debugger mir einen sinnvollen Call-Stack liefert. Ich habe in den letzten drei Wochen schon unzählige Stunden damit verbracht, der Ursache auf die Schliche zu kommen. Je nachdem, wie ich den Ablauf strukturiere, crasht es mal, nachdem die Indy-Library geladen ist oder bei der initialization des Main-Package oder oder oder. Mal ist es eine Access Violation, mal eine Priviledged Instruction.

Nur wenn ich alle .bpl- und .dll-Dateien zusammen mit der .exe in ein Verzeichnis werfe, alle Packages als Runtime-Packages in den .exe-Optionen angebe und die Main-Unit einbinde, um Delphi das automatische (verzögerte) Laden zu überlassen, läuft das Programm durch. Wenn ich stattdessen auch nur folgendes minimale Programm laufen lasse, crasht es bei der initialization der Main-Unit:

Code:

begin
  SetDllDirectory(PWideChar('C:\PfadZuDenLibs\'));
  LoadPackage('bnMain270.bpl');
end.

Endlose Google-Suchen waren ergebnislos. Ich bräuchte bitte mal einen heißen Tipp, wie ich dem Problem auf die Schliche kommen kann.

Viele Grüße
Boris

[Delphi.Narium]

Versuch bitte mal etwas in dieser Art:

Delphi-Quellcode:

// Die Umgebungsvariabel Path um unser eigenes Suchverzeichnis erweitern.
function AddDllDirectoryToPath(ADirectory : String) : Boolean;
var
  sPath : String;
begin
  sPath := GetEnvironmentVariable('PATH');
  if Pos(ADirectory,sPath) = 0 then sPath := Format('%s;%s',[ADirectory,sPath]);
  SetEnvironmentVariable('PATH', PChar(sPath));
  sPath := GetEnvironmentVariable('PATH');
  // Sofern das Verzeichnis ADirectory noch nicht in der Pfadangabe enthalten war,
  // sollte es nun an der ersten Stelle des Suchpfades stehen.
  ShowMessage(sPath); // <-- das ShowMessage kann im Programmablauf natürlich verschwinden ;-)
  Result := Pos(ADirectory,sPath) <> 0;
end;


const
  csLibDir = 'C:\PfadZuDenLibs\';

begin
  if not AddDllDirectoryToPath(csLibDir) then
  begin
    // Fehlerbehandlung, Programmabbruch ... oder ... oder ... oder ...
  end;
end;

Diesen Teil bitte "irgendwo" vor dem ersten Laden von Packages ... im Programm einbauen.

Sinn: Eventuell werden die Packages ... nicht gefunden. Im Programmablauf werden DLL's ... zuerst im Exe-Verzeichnis gesucht. Sind sie dort nicht zu finden, wird die Umgebungsvariabel Path "abgegrast", bis was gefunden wurde. Wird nix gefunden, gibt es eine Fehlermeldung (hoffentlich).
Wenn die Packages im Exe-Verzeichnis liegen, scheint diese Logik ja zu funktionieren. Es könnte sich beim Beschriebenen also um ein Problem bei der Suche nach Packages ... handeln.
Sollten über die PATH-Variabel jetzt zufällig noch ältere Versionen der Packages zu finden sein, könnte auch dies ein möglicher Grund für das beschriebene Problem sein. (Bitte vorsichtshalber mal überprüfen, nicht nur in Bezug auf Deine eigenen Sachen, sondern bei Indy z. B. auch nach den Packages, die von den Indy-Packages aufgerufen werden könnten.)

Und nein, das muss jetzt keine Lösung des Problemes sein, aber eventuell hilft es ja bei der weiteren Ursachenforschung.

[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?

[neubert]

So, es war sehr mühsam aber ich habe es geschafft. Habe mein Main-Package von Grund auf schrittweise neu aufgebaut und dabei noch einige kleinere Änderungen vorgenommen - der Kode ist also nicht ganz identisch und das scheint die Probleme zu vermeiden. Nun lässt es sich ohne internen Fehler kompilieren und läuft auch komplett richtig durch. Als nächstes muss ich die zwei Packages, die ich bei der Fehlersuche als weitere Störenfriede/Absturzverursacher identifiziert und vorübergehend ausgebaut habe, anders neu aufbauen, um die dadurch entfernte Funktionalität wiederzugewinnen.

Danke für Eure Unterstützung.

Die Tipps zu den Verzeichnissen und zum Manifest helfen mir zusätzlich. Dafür ein extra Dank!