FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[taveuni]

O.K. Das war ja einfach Das ist der Verusacher:

Delphi-Quellcode:

procedure TDetectionCore.CopyPictures(PicFrom, PicTo: String);

function CopyFileEx(const ASource, ADest: string; ARenameCheck: boolean = false): boolean;
var
  sh: TSHFileOpStruct;
begin
  // so was hat offensichtlich gefehlt. Das war im Original nicht drin.
{--->} FillChar(sh,SizeOf(sh),0); {<---}
  sh.wFunc := FO_COPY;
  sh.pFrom := PChar(ASource + #0);
  sh.pTo := PChar(ADest + #0);
  sh.fFlags := fof_Silent or fof_MultiDestFiles;
  if ARenameCheck then
    sh.fFlags := FOF_NOCONFIRMATION;
  Result:=ShFileOperation(sh)=0;
end;

begin
  FFileLock.Enter;
  Try
    if ForceDirectories(ExtractFilePath(PicTo)) then
    begin
      if not CopyFileEx(PicFrom, PicTo, True) then
        LogError('could not copy File:%s to:%s',[PicFrom,PicTo]);
    end
    else
      LogError('could not create directory: %s',[ExtractFilePath(PicTo)]);
  Finally
    FFileLock.Release;
  End;
end;

Muss ich das einfach wissen? Vermutlich würde auch ZeroMemory gehen? Diese Struktur ist als Record definiert. Und der Record wird der Funktion ShFileOperation als const übergeben. Üble Sache. Müssen Records grundsätzlich so behandelt werden? Oder nur mit Windows eigenen Funktionen?

Nebenbei: Bevor ich auf das gekommen bin habe ich die Copyfunktion durch das ersetzt:

Delphi-Quellcode:

var
  mem: TMemoryStream;
begin
  FFileLock.Enter;
  Try
    mem:= TMemoryStream.Create;
    if ForceDirectories(ExtractFilePath(PicTo)) then
    begin
      mem.LoadFromFile(PicFrom);
      mem.SaveToFile(PicTo);
    end
  Finally
    mem.Free;
    FFileLock.Release;
  End;

Gibt es da eine Präferenz bezüglich Geschwindigkeit oder anderen Gesichtspunkten das Eine oder das Andere zu nutzen?

Auf jeden Fall: Ich danke Euch vielmals für Eure Hinweise. Besonders nachdem FastMM zufrieden war hätte ich nicht weiter gewusst.
Jetzt kann ich endlich aus dem Memory Loch wieder herauskriechen

Gruss Werner