Delphi-DLL mit PAnsiChar: Zugriffsverletzung bei Freigabe

[hsg]

Hallo,

ich bin gerade mal wieder leicht am Verzweifeln. Ich erstelle zurzeit eine Delphi-DLL mit einem ganzen Haufen von Funktionen, die sowohl in einem Delphi-Programm als auch in VBA genutzt werden sollen. Daher verwende ich in der DLL AnsiString bzw. PAnsiChar zur Übergabe von String-Parametern.

Die größten Hindernisse habe ich dabei bereits umschifft, doch im Moment kämpfe ich mit einem Phänomen, das ich mir nicht erklären kann.

Die DLL-Funktion sieht dabei wie folgt aus:

Delphi-Quellcode:

Function UserHatRecht(cPObj, cPRecht : PAnsiChar): Boolean; stdCall;
var
  cSql          : String;
  lResult       : Boolean;
  cObj, cRecht  : String;
begin
  cObj                  := String(cPObj);
  cRecht                := String(cPRecht);
  Result                := false;
  lResult               := False;
  // mittelglroßes SQL-Statement entfernt, 
  Result                := lResult;
end;

Im DelphiProgramm steht dann folgendes:

Delphi-Quellcode:

interface

  Function UserHatRecht( cObj, cRecht : string): Boolean;
  Function DLL_UserHatRecht( cObj, cRecht : PAnsiChar): Boolean; stdCall; external 'FSGVBA.dll' name 'UserHatRecht';

implementation

function HoleSpeicher( cVal : string) : PAnsiChar;
var
  pPtr    : Pointer;
  nLen    : Integer;
  cAVal   : AnsiString;
begin
  cAVal       := AnsiString(cVal);
  nLen        := Length(cAVal);
  GetMem( pPtr, nLen);
  StrLCopy(pPtr, PAnsiChar(cAVal), nLen);
  Result      := pPtr;
end;

Function UserHatRecht( cObj, cRecht : string): Boolean;
var
  pO, pR : PAnsiChar;
begin
  // Vorbereitung:
  pO    := HoleSpeicher(cObj);
  pR    := HoleSpeicher(cRecht);
  // Ausführung:
  Result  := DLL_UserHatRecht(pO, pR);
  // Aufräumen:
  FreeMem(pO); // <-- hier kommt die Zugriffsverletzung
  FreeMem(pR);
end;

Kommentiere ich die Zeile aus, in der die Zugriffsverletzung passiert, läuft das Programm ohne Probleme weiter.
Ich rufe an anderen Stellen bereits andere Funktionen aus der DLL auf, bei der zum Teil sogar Strings zurückgegeben und deutlich mehr Parameter an die DLL übergeben werden, ohne dass etwas passiert. Nur bei dieser Funktion knallt es.
Irgendjemand eine Idee, was hier schiefläuft?

Gruß
hsg

[hoika]

Hallo,
was mir komisch vorkommt.
Du sprichst überall von Ansi, hier aber benutzt du den normalen Delphi-String.

cObj := String(cPObj);

Und benutzt z.B. nicht deine StrLCopies, um den String zu füllen.
cObj liegt ja auf dem Stack und wird "hinter" dem end freigegeben.
Was dann mit cPObj ist, mag ich mir gerade nicht ausdenken ...

[Rudy Velthuis]

Zitat von hsg:

Hallo,

Im DelphiProgramm steht dann folgendes:

Delphi-Quellcode:

interface

  Function UserHatRecht( cObj, cRecht : string): Boolean;
  Function DLL_UserHatRecht( cObj, cRecht : PAnsiChar): Boolean; stdCall; external 'FSGVBA.dll' name 'UserHatRecht';

implementation

function HoleSpeicher( cVal : string) : PAnsiChar;
var
  pPtr    : Pointer;
  nLen    : Integer;
  cAVal   : AnsiString;
begin
  cAVal       := AnsiString(cVal);
  nLen        := Length(cAVal);
  GetMem( pPtr, nLen);
  StrLCopy(pPtr, PAnsiChar(cAVal), nLen);
  Result      := pPtr;
end;

Function UserHatRecht( cObj, cRecht : string): Boolean;
var
  pO, pR : PAnsiChar;
begin
  // Vorbereitung:
  pO    := HoleSpeicher(cObj);
  pR    := HoleSpeicher(cRecht);
  // Ausführung:
  Result  := DLL_UserHatRecht(pO, pR);
  // Aufräumen:
  FreeMem(pO); // <-- hier kommt die Zugriffsverletzung
  FreeMem(pR);
end;

Wozu soll HoleSpeicher gut sein? Du allozierst Speicher (übrigens zu wenig, denn du vergisst das #0-Zeichen am Ende), der dann irgendwann wieder freigegeben werden muss, aber wofür?

Mache es doch nicht schwieriger als es ist, sondern einfach so:

Delphi-Quellcode:

function UserHatRecht(cObj, cRecht: string): Boolean;
begin
  Result := DLL_UserHatRecht(PAnsiChar(AnsiString(cObj)), PAnsiChar(AnsiString(cRecht)));
end;

Es wäre anders, wenn du die Strings als Rückgabe-Puffer benötigen solltest, aber das ist ja hier nicht der Fall.

Übrigens, du solltest mal meinen Artikel (nur in English, sorry) über DLLs lesen: DLL dos and don'ts. Da steht auch, wie man Puffer übergeben kann.

[hsg]

Moin,
erst einmal Danke für die bisherigen Antworten.

Zitat von Rudy Velthuis:

Wozu soll HoleSpeicher gut sein? Du allozierst Speicher (übrigens zu wenig, denn du vergisst das #0-Zeichen am Ende), der dann irgendwann wieder freigegeben werden muss, aber wofür?

Mache es doch nicht schwieriger als es ist, sondern einfach so:

Delphi-Quellcode:

function UserHatRecht(cObj, cRecht: string): Boolean;
begin
  Result := DLL_UserHatRecht(PAnsiChar(AnsiString(cObj)), PAnsiChar(AnsiString(cRecht)));
end;

Es wäre anders, wenn du die Strings als Rückgabe-Puffer benötigen solltest, aber das ist ja hier nicht der Fall.

Übrigens, du solltest mal meinen Artikel (nur in English, sorry) über DLLs lesen: DLL dos and don'ts. Da steht auch, wie man Puffer übergeben kann.

Der Hinweis mit dem zu kleinen Speicher wars. Jetzt scheint es zu laufen.

Die Funktion habe ich als Verzweiflungstat eingeführt, weil meine vorherigen Versuche alles mögliche ergaben, nur nicht das erwünschte. Unter anderem stand in einer Version in allen Parametern das gleiche. Inzwischen ist mir klar, was ich dort falsch gemacht habe, doch da hatte ich bereits die Funktion eingebaut und die meisten Stellen geändert.

Danke für den Link, ich werde ihn mir gleich in aller Ruhe zu Gemüte führen.

Zitat von hoika:

Hallo,
was mir komisch vorkommt.
Du sprichst überall von Ansi, hier aber benutzt du den normalen Delphi-String.

cObj := String(cPObj);

Und benutzt z.B. nicht deine StrLCopies, um den String zu füllen.
cObj liegt ja auf dem Stack und wird "hinter" dem end freigegeben.
Was dann mit cPObj ist, mag ich mir gerade nicht ausdenken ...

Die Parameter sind alle in PAnsiChar, da allerdings die eigentlichen Funktionen zum Teil andere Funktionen nutzen, die wiederum Strings erwarten/liefern, habe ich die Parameter wieder in Strings gewandelt. Ich muss allerdings gestehen, dass mir nicht ganz klar ist, was Delphi hier wirklich macht: Eigentlich müsste doch Delphi für cObj einen komplett neuen Speicherbereich anlegen und bei der Zuweisung von String(cPobj) den Inhalt aus cPObj in cOBJ kopieren, oder etwa nicht? Schließlich ist cObj ein Unicode-String und damit doppelt so groß wie der AnsiString in cPObj
StrLCopy wäre doch hier dann eh falsch, da es mit (P)AnsiChar arbeitet?

Gruß
hsg

[hoika]

Hallo,

Zitat:

Eigentlich müsste doch Delphi für cObj einen komplett neuen Speicherbereich anlegen und bei der Zuweisung von String(cPobj) den Inhalt aus cPObj in cOBJ kopieren, oder etwa nicht?

Das glaube ich nicht.
Das ist ja gerade das gefährliche von TypeCasts. Du umgehst die komplette Typ-Prüfung und oft auch die "Compiler-Magie" bei Strings.
Im Zweifel kannst du ja den Assembler-Code mit einblenden. Zumindestens Copy-Befehle oder deren nicht Vorhandensein müssten zu sehen sein.

[hsg]

Ich habe mir jetzt mal angesehen, was an der Stelle passiert. Leider reichen meine Assembler-Kenntnisse nicht mehr aus, um wirklich alles zu verstehen.

Allerdings wird der PAnsiChar über einen festen Zwischenbuffer (Buffer: array[0..2047] of WideChar) und der Microsoft-Funktion MultiByteToWideChar in einen Unicode-String gewandelt, der dann über neu allozierten Speicher zurückgegeben (System.GetMem wird explizit aufgerufen) wird.
Von daher ist die Konvertierung wohl an der Stelle gefahrlos.