DLL mit Runtime-Packages: Entladehemmung!?

[BGeers]

Hallo,

Die Architektur unseres Projekts besteht aus einer Exe-Datei und dynamisch ladbaren Dlls. Bei der Umstellung von Delphi 4 auf Delphi 2006 treten nun verstärkt Probleme mit dem is - Operator auf, so daß wir eine Alternative suchen.

Die Verwendung von Runtime-Packages in der Exe sowie den Dlls für alle Borland- und Zukauf-Units bewirkt, daß die Anwendung zufriedenstellend läuft, beim Schließen wird sie aber nicht mehr entladen, sobald 2 Dlls mit Runtime-Packages geladen wurden. Bei Verwendung des LCPI-OLE DB Providers für Firebird tritt zusätzlich in einer zugehörigen DLL eine Schutzverletzung auf.
Wir haben schon darauf geachtet, das jedes LoadLibrary durch ein FreeLibrary und jedes CoInitialize durch ein CoUnInitialize aufgehoben wird.

Gibt es noch etwas, worauf wir achten müssen oder müssen wir unsere DLLs komplett zu dynamisch zu ladenden Runtime-Packages umbauen ?

Über einen Hinweis würden wir uns freuen.

[Robert Marquardt]

Der is Operator basiert auf den RTTI-Daten. Eine Delphi-DLL hat nicht nur einen eigenen Memory-Manager, sondern daraus folgend auch eigene RTTI-Daten. is kann also schiefgehen. ShareMem verbindet die Memory-Manager. Soweit ich weiss muss aber noch mehr getan werden, damit das RTTI auch laeuft. Genau diese Zusatzleistungen erbringt das Package.

[BGeers]

Das Nichtfunktionieren des is - Operators aufgrund unschiedlicher RTTI-Objekte lässt sich auch schön im Debugger verfolgen. Das darufhin erzielte Ergebnis ist auch eindrucksvoll: "TFont ist nicht vom Typ TFont".
Deshalb nutzten wir die Runtime-Packages, geraten aber nun mit unseren DLL's vom Regen in die Traufe: Eine von ihnen lässt sich schön laden und entladen, bei der zweiten knallts am Programmende. In Kürze das was ich über das Problem weiss:
- Es reicht, eine zweite DLL zu laden und sofort zu entladen: Knall!!
- vollkommen entleerte DLL laden und entladen: dito
- wo knallt es: verantwortlich ist der Handlungsstrang nach ExitProcess (_Halt0 in system.pas). FinalizeUnits läuft also noch ohne Probleme durch
- verantwortlich scheinen die OLE-DB-Treiber zu sein. Je nach verwendeter DB (Firebird oder Oracle) werden unterschiedliche Fehler kredenzt.
- im Speicher bleiben Objekte vom Typ AdoDB.asyncEventMessenger stehen; gilt für beide DB's

Verzichte ich auf Runtime-Packages, bleiben die Fehler aus.

Alternativ: Vielleicht weiss jemand, wie sich RTTI-Barrieren tunneln lassen??

[Bernhard Geyer]

Euer Problem ist das eure Lösung unter Delphi 4 funktionierte obwohl dort die gleichen Probleme vorliegen, jedoch zufälligerweise nicht die Probleme verursacht hat.
Falls es die OLE DB-Provider sind: Wird hier u.U. "versehentlich" CoInitialize im finalization einer Unit aufgerufen?
Ansonsten: Was stört es wenn die BPL's geladen bleiben. So viel mehr an Speicher wird wohl nicht verbraten.

[BGeers]

Ohne Zweifel: Delphi4 hat einiges unter dem Mantel der Verschwiegenheit verschwinden lassen, was jetzt hochkommt.

Leider ist es nicht damit getan, dass die Anwendung nicht sauber beim Betriebssystem ausgetragen wird. Nachfolgende Aufrufe reagieren in der Oracle-Version sehr ungehalten auf die herumliegenden Trümmer des Vorgängers und stellen die Mitarbeit ein. Unter Firebird wird am Ende zwar erfolgreich aufgeräumt, aber erst nach 3 mit Tamm-Tamm veröffentlichten Exceptions. Wenn die Kunden nicht so pingelig wären, ...

Vielen Dank zum Hinweis auf das fehlplazierte CoInitialize. Wie werden suchen.

[Bernhard Geyer]

Ich würde für Oracle und Firebird eh keine ADO-Basierenten DB-Zugriff nehmen. Dafür gibt es direktere Möglichkeiten. U.a. auch welche die z.B. keinen installierten Oracle-Client benötigen.

[Robert Marquardt]

Wenn schon die finalization sections geprueft werden, dann sollte man dort alle globalen Variablen sauber zuruecksetzen, also FreeAndNil verwenden bzw. analoges Ruecksetzen. Das hat uns bei den JVCL Packages in der IDE immer Probleme bereitet bis wir es ausgemistet hatten.

[BGeers]

Die JVCL ist bei uns auch im Einsatz. Danke für den Hinweis! Ich fang mal an zu graben.

[BGeers]

Lösung gefunden: Problem liegt in der aktuellen Sharemem-Implementierung: Problembeschreibung und -lösung findet sich unter: http://qc.codegear.com/wc/qcmain.aspx?d=8639

[mirage228]

Hallo,

Eventuell lohnt ja ein Umstieg auf FastMM4 - dort wird auch eine FastMM4-Version der borlndmm.dll mitgeliefert.
Hätte auch den Vorteil, dass FastMM4 schneller ist.

mfG
mirage228