ShareMem bzw. FastMM mit DLL

[ele]

Hallo,

Ich habe ein kleines Problem und hoffe, dass mir jemand dabei weiterhelfen kann.

Ich bin dabei ein Webserver in Delphi 2010 zu Programmieren. Dieser kann Web Applications laden, die in Form einer Plugin-DLL vorliegen. Die Schnittstelle benutzt Interfaces, weswegen der Einsatz von ShareMem nötig ist. Soweit so gut, funktioniert alles prima nur funktioniert das ReportMemoryLeaksOnShutdown nicht. (Also es gibt nicht direkt eine Fehlermeldung, aber das setzen des Wertes hat einfach keine Auswirkungen. Ich denke das der Memory Manager von ShareMem diese Funktion einfach nicht unterstützt).

Ich habe auch schon versucht, das ganze mit FastMM zu lösen, aber dann kriege ich Zugriffsverletzungen. Verschiedene Konfigurationen in der FastMMoptions.inc haben bisher auch nicht gefruchtet (ShareMM, ShareMMIfLibrary, AttemptToUseSharedMM).

Ist es irgendwie möglich die Vorteile von ShareMem und FastMM zu kombinieren? Oder anders gesagt: Wie kann ich diese Applikation bzw. Plugins auf Memory Leaks prüfen?

[himitsu]

ReportMemoryLeaksOnShutdown gehört NUR zum Delphiinternen Speichermanager (FastMM)

Wenn man aber ShareMem oder ein externes FastMM nutzt, dann wird der interne Speichermanager durch den externen ersetzt, weßhalb ReportMemoryLeaksOnShutdown da keinen Einfluß haben kann.

Zitat von ele:

Die Schnittstelle benutzt Interfaces, weswegen der Einsatz von ShareMem nötig ist.

Ein Interace selber setzt kein ShareMem voraus ... das ist ja schließlich ein Vorteil gegenüber Objekten.

Welche Parameter/Results setzen denn dieses voraus?

Wenn man da nur Typen nutze, welche nicht über Delphis Speichermanager laufen, dann benötigt man kein ShareMem.
> WideString statt String/AnsiString/UnicodeString
> keine dynamischen Arrays
> keine Objekte
> ...

[ele]

Ich habe zwei Funktionen die mein Plugin exportiert:

Delphi-Quellcode:

function GetInterfaceVersion(): AnsiString;
begin
  Result := rbInterfaceVersion;
end;

function RegisterWebApplication(ARaspberryServerAPI: IrbAPI): IrbWebApplication;
begin
  Result := TrbwDemoWebApp.Create(ARaspberryServerAPI);
end;

Also habe ich nach deinem Vorschlag AnsiString in WideString geändert:

Delphi-Quellcode:

function GetInterfaceVersion(): WideString;
begin
  Result := rbInterfaceVersion;
end;

Das scheint anfangs ganz gut zu funktionieren, aber beim Beenden des Programmes knallts dann doch.

Ich habe das Gefühl, das Interfaces alleine mich nicht retten, da die Interfaces Methoden deklarieren, die ihrerseits wieder Strings und Delphi-Objekte als Parameter haben. Dies könnte ein Hinweis sein:

Zitat:

{ Important note about DLL memory management: ShareMem must be the
first unit in your library's USES clause AND your project's (select
Project-View Source) USES clause if your DLL exports any procedures or
functions that pass strings as parameters or function results. This
applies to all strings passed to and from your DLL--even those that
are nested in records and classes. ShareMem is the interface unit to
the BORLNDMM.DLL shared memory manager, which must be deployed along
with your DLL. To avoid using BORLNDMM.DLL, pass string information
using PChar or ShortString parameters. }

Ich weiss, dass es schwer nachzuvollziehen ist, wenn man keinen Code hat. Aber weil ich mein Mammut-Projekt schlecht in das Forum stellen kann, habe ich husch husch eine kleine Demo-Anwendung zusammengestellt, die im wesentlichen gleich funtioniert. Es wäre auch ein hübsches Beispiel wie man ein Plugin programmiert, wenn es dazu nicht schon genug Beiträge gäbe. (Wer ein funktionierendes Beispiel will muss halt FastMM4 durch ShareMem ersetzen und die borlndmm.dll ins Exe-Verzeichnis stellen).

Wenn jemand da reinblicken könnte, wäre ich sehr dankbar.

[Zacherl]

Vielleicht irre ich mich, aber wird WideString nicht auch von Delphis MM verwaltet? Für InterfaceVersion könntest du doch einfach eine Nummer nehmen oder nicht? Alternativ einen String mit begrenzten Zeichen, also array[1..32] of Char oder sowas.

[himitsu]

Nein, WideString ist eine Umleitung um OLE-String, welcher über die OleAuth.dll verwaltet wird.
Außerdem kennt auch C diesen String, somit ist es auch praktisch für Plugins in anderen Sprachen.

[ele]

Ich habe es jetzt hingekriegt... es lag daran, dass ich vor dem FreeLibrary die Interface-Variable nicht auf nil gesetzt hatte. Ich habe das Beispiel korrigiert, läuft jetzt einwandfrei. Auch wenns keine sau zu interessieren scheint...

Trotzdem danke an euch.

Edit: Noch als hinweis, falls jemand das gleiche Problem hat: Die Option RequireDebuggerPresenceForLeakReporting muss ausgeschaltet sein, das funktioniert anscheinend nicht mit dynamisch geladenen DLLs.

[ele]

Ich hatte einen harten Kampf gegen Delphi um das ganze zum laufen zu bringen, wenn aus der DLL Exceptions geworfen werden. Den Kampf habe ich dann gewonnen, das Resultat ist im Anhang.

Leider muss nun jede Methode, welche in der DLL implementiert wird beim Aufruf durch einen Try Except Block geschütz werden:

Delphi-Quellcode:

procedure TPlugin.SayHello(const Language: String);
var
  ErrorMessage: String;

begin
  try
    FPluginDLL.SayHello(Language); // Aufruf der DLL-Methode
  except
    On E: Exception do
    begin
      ErrorMessage := E.Message;
      UniqueString(ErrorMessage);
      raise Exception.Create(ErrorMessage);
    end;
  end;
end;

Das ganze ist einwenig mühsam, besonders wenn in der DLL viele Methoden implementiert sind. Leider wüsste ich keine Möglichkeit um das zu vereinfachen. Sowas wie

Delphi-Quellcode:

procedure TPlugin.SayHello(const Language: String);
var
  ErrorMessage: String;

begin
  ProtectedCall(FPluginDLL.SayHello(Language)); // Aufruf der DLL-Methode
end;

wäre schön, ist aber so wie ich das sehe nicht realisierbar, da Delphi keine Makros kennt.
Schade...