Interface Problem - AV beim Beenden des Programms

[Aviator]

Hallo Delphianer,

nachdem ich einige Hilfe im Bezug auf DLL Programmierung von euch erhalten habe, habe ich ein weiteres Problem.

Aktuell habe ich folgenden Aufbau:

• User DLL (DLL zum Verwalten und zum Auslesen von Benutzerdaten aus einer Datenbank)
• Session DLL (DLL um eine SessionID zu erzeugen mit der ein Benutzer nach der Anmeldung arbeiten kann)
• 2 unterschiedliche Interfaces

Ich denke, dass der Aufbau der Interfaces in der Sache egal ist. Deshalb poste ich die im Moment mal nicht. Sollten sie dennoch benötigt werden, dann kann ich sie natürlich einstellen.

Beim Start des Programmes lade ich beide DLLs. Eine DLL stellt nur eine Methode, die andere zwei im Export Abschnitt zur Verfügung, welche jeweils eine Interface Instanz zurückgeben. Das funktioniert soweit auch alles perfekt. Als Übergabeparameter erhält die exportierte Methode ein Interface, welches Datenbank Verbindungsparameter zur Verfügung stellt.

Delphi-Quellcode:

function GetInstance{(DataBaseConnectionInfo: IDataBaseConnectionInfo)}: IDMSSession; stdcall;
begin
  Result := TSessionManager.Create{(DataBaseConnectionInfo)};
end;


exports
  GetInstance;

Delphi-Quellcode:

function GetInstanceInt(DataBaseConnectionInfo: IDataBaseConnectionInfo): IDMSUserManager; stdcall;
begin
  Result := TDMSUserManager.Create(DataBaseConnectionInfo) as IDMSUserManager;
end;

function GetInstanceExt(DataBaseConnectionInfo: IDataBaseConnectionInfo): IDMSUserExchanger; stdcall;
begin
  Result := TDMSUserManager.Create(DataBaseConnectionInfo) as IDMSUserExchanger;
end;

exports
  GetInstanceInt,
  GetInstanceExt;

Die erste DLL (User DLL) kann ich problemlos laden und auch Funktionen darin aufrufen.

Die zweite DLL (Session DLL) lässt sich laden, ich kann auch Funktionen daraus aufrufen, aber beim Beenden des Programms schmiert die Anwendung mit einer AV ab.
Alle Aufrufkonventionen stimmen überein, es werden keine

Delphi-Quellcode:

const

Parameter verwendet wenn ich Interfaces zurückgebe, ...

Das an beide DLLs übergebene Interface habe ich testweise auch ein zweites Mal als zusätzliche Instanz erzeugt und auch mal ganz weggelassen (siehe die Codebeispiele oben). Trotzdem der gleiche Fehler. Nehme ich die Session DLL komplett raus, passiert gar nichts (wie erwartet). Lasse ich die Session DLL drin und nehme die User DLL raus, schmiert das Programm auch ab. Es hängt also wohl mit der Session DLL zusammen.

Die Fehlermeldung lautet:

Im Projekt Project1.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x0040d9a2: read of address 0x03fa9bc8' aufgetreten.

Das Programm beendet sich sauber, wenn ich die Variable der das Interface zugeordnet wurde vor dem Freigeben der Klasse in der die Variable verwaltet wird auf nil setze.

Warum ist das so? Wieso funktioniert es bei einer DLL und bei einer andere nicht?

Das Programm schmiert in der System.pas in der folgendes Procedure ab. Deshalb dachte ich, dass das etwas mit den Interfaces zu tun haben muss. Nur weiß ich nicht was.

Delphi-Quellcode:

function _IntfClear(var Dest: IInterface): Pointer;
{$IFDEF PUREPASCAL}
var
  P: Pointer;
begin
  Result := @Dest;
  if Dest <> nil then
  begin
    P := Pointer(Dest);
    Pointer(Dest) := nil;
    IInterface(P)._Release;
  end;
end;
{$ELSE !PUREPASCAL}
{$IFDEF CPUX86}
asm
        MOV     EDX,[EAX]
        TEST    EDX,EDX
        JE      @@1
        MOV     DWORD PTR [EAX],0
{$IFDEF ALIGN_STACK}
        SUB     ESP, 4
{$ENDIF ALIGN_STACK}
        PUSH    EAX
        PUSH    EDX
        MOV     EAX,[EDX]  // <---------  Hier bleibt der Debugger stehen!!!!!!!!!!!!!!
        CALL    DWORD PTR [EAX] + VMTOFFSET IInterface._Release
        POP     EAX
{$IFDEF ALIGN_STACK}
        ADD     ESP, 4
{$ENDIF ALIGN_STACK}
@@1:
end;
{$ENDIF CPUX86}
{$ENDIF !PUREPASCAL}

Ich hoffe, dass mir jemand bei dem Problem helfen kann. Ich weiß langsam wirklich nicht mehr weiter.

[Fritzew]

Zitat:

Das Programm beendet sich sauber, wenn ich die Variable der das Interface zugeordnet wurde vor dem Freigeben der Klasse in der die Variable verwaltet wird auf nil setze.

Das ist das richtige Vorgehen. Nur dann kannst Du sicher sein wann das Interface freigegeben wird.
Wahrscheinlich ist die Dll schon gar nicht mehr geladen wenn es bei Dir knallt.

[Aviator]

Zitat:

Zitat von Fritzew (Beitrag 1351103)

Zitat:

Das Programm beendet sich sauber, wenn ich die Variable der das Interface zugeordnet wurde vor dem Freigeben der Klasse in der die Variable verwaltet wird auf nil setze.

Das ist das richtige Vorgehen. Nur dann kannst Du sicher sein wann das Interface freigegeben wird.
Wahrscheinlich ist die Dll schon gar nicht mehr geladen wenn es bei Dir knallt.

Ach echt? Ich dachte immer, dass das egal sei. Interface-Instanzen geben sich doch selbst frei wenn die Referenzzählung auf 0 runter geht.

Und ja, die DLL wird vorher von mir entladen. Nur wieso funktioniert es bei der einen DLL und bei der andere nicht? Und gerade bei der, bei der es nicht funktioniert, rufe ich nicht mal eine Funktion auf. Ich lade sie nur und lasse mir eine Instanz geben. Das war es auch schon. Mit der anderen DLL arbeite ich bereits schon durchgehend und da passiert nichts.

[Fritzew]

Zitat:

Und ja, die DLL wird vorher von mir entladen. Nur wieso funktioniert es bei der einen DLL und bei der andere nicht? Und gerade bei der, bei der es nicht funktioniert, rufe ich nicht mal eine Funktion auf. Ich lade sie nur und lasse mir eine Instanz geben. Das war es auch schon. Mit der anderen DLL arbeite ich bereits schon durchgehend und da passiert nichts.

Einfache Regel: Wenn Du die Dll entlädst darf keine Referenz auf ein Interface der Dll mehr da sein.
Ansonsten wird beim Versuch das freizugeben code aufgerufen den es gar nicht mehr gibt.
Und ja greift auch die Referentzählung aber was soll den dann gemacht werden. Kann ja nicht gehen wenn die dll nicht mehr da ist.

Und du rufst Code auf in dem Du eine Instanz holst.

Die Klasse existiert ja in Deiner DLL.

[DeddyH]

http://www.delphipraxis.net/189047-[erledigt]-interface-aus-dll-per-latebinding-freelibrary-toedlich.html
Vielleicht hilft es.

[Aviator]

Zitat:

Zitat von Fritzew (Beitrag 1351109)

Zitat:

Und ja, die DLL wird vorher von mir entladen. Nur wieso funktioniert es bei der einen DLL und bei der andere nicht? Und gerade bei der, bei der es nicht funktioniert, rufe ich nicht mal eine Funktion auf. Ich lade sie nur und lasse mir eine Instanz geben. Das war es auch schon. Mit der anderen DLL arbeite ich bereits schon durchgehend und da passiert nichts.

Einfache Regel: Wenn Du die Dll entlädst darf keine Referenz auf ein Interface der Dll mehr da sein.
Ansonsten wird beim Versuch das freizugeben code aufgerufen den es gar nicht mehr gibt.
Und ja greift auch die Referentzählung aber was soll den dann gemacht werden. Kann ja nicht gehen wenn die dll nicht mehr da ist.

Und du rufst Code auf in dem Du eine Instanz holst.

Die Klasse existiert ja in Deiner DLL.

Okay! Ist verständlich. Danke für die Info. :thumb:

Zitat:

Zitat von DeddyH (Beitrag 1351110)

http://www.delphipraxis.net/189047-[erledigt]-interface-aus-dll-per-latebinding-freelibrary-toedlich.html
Vielleicht hilft es.

Ist ja eigentlich das Gleiche was Fritzew auch schon geschrieben hat. Dennoch danke dafür. :mrgreen:
Überlege, ob ich das dann auch ganz raus lasse. Nur räume ich eben immer gerne selbst alles auf was ich benutzt habe. In dem Fall kann ich auch eigentlich sicher sein, dass ich die DLL(s) nicht mehr benötige.

[jaenicke]

Dafür gibt es in unserer DLL Schnittstelle ein Shutdown. Das wird vor dem Entladen aufgerufen, daraufhin koppelt sich die DLL aus allen Eventhandlern usw. aus.