AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
O.K. Das war ja einfach :roll: Das ist der Verusacher:
Delphi-Quellcode:
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?
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; Nebenbei: Bevor ich auf das gekommen bin habe ich die Copyfunktion durch das ersetzt:
Delphi-Quellcode:
Gibt es da eine Präferenz bezüglich Geschwindigkeit oder anderen Gesichtspunkten das Eine oder das Andere zu nutzen?
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; 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 :-D Gruss Werner |
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Wenn Du einen Record mit Werten belegst, dann musst Du alle Werte explizit belegen, ansonsten steht da doch Müll drin. Sehr unsauber. Das hier ein Speicherleck entsteht, hätte ich nicht gedacht, aber das es überhaupt funktioniert, wundert mich schon.
|
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Nebenbei:
Zitat:
Delphi-Quellcode:
sh.fFlags := sh.fFlags or FOF_NOCONFIRMATION;
|
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Was ich gerade gesehen habe: Der Record in der ShellApi ist so definiert:
Delphi-Quellcode:
Also pFrom und pTo sind WideChar. In der Funktion werden die aber als PChar gecastet. Ist das vielleicht nicht so gut?
_SHFILEOPSTRUCTW = record
Wnd: HWND; wFunc: UINT; pFrom: PWideChar; pTo: PWideChar; fFlags: FILEOP_FLAGS; fAnyOperationsAborted: BOOL; hNameMappings: Pointer; lpszProgressTitle: PWideChar; @DeddyH: Ja logisch - völliger Unsinn. @Dejan Vu: Keine Ahnung wie Du das meinst. pFrom und pTo sind Variablen eines Records. Was soll man da komplett(er) belegen? |
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
In Delphi >= 2009 ist PChar ein PWideChar, davor war es PAnsiChar. In neueren Delphi-Versionen ist es für die Funktionalität also nicht von Bedeutung, allerdings unsauber IMO.
|
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Es ist völlig ok hier mit
Delphi-Quellcode:
zu arbeiten, denn es wird ja auch mit
PChar
Delphi-Quellcode:
und mit
TSHFileOpStruct
Delphi-Quellcode:
gearbeitet und eben nicht mit den expliziten Ansi oder Wide Varianten.
SHFileOperation
Hier wird je nach Compiler-Version automatisch zwischen der Ansi und Wide Variante gewechselt, genau so, wie auch
Delphi-Quellcode:
dann in der Bedeutung (
PChar
Delphi-Quellcode:
vs
PAnsiChar
Delphi-Quellcode:
) wechselt.
PWideChar
Es ist also nicht unsauber, sondern genau richtig! |
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Zitat:
Tipp: Da ich eh nicht weiß, wie ein bestimmter Parameterrecord deklariert ist, kopiere ich mir immer die Deklaration in meinen Code und belege dann alle Werte. Das ist viel einfacher, als zu überlegen, was man so alles braucht. Außerdem bin ich so auch gegen Veränderungen gewappnet, da der Programmierer nicht mehr nachschauen muss, welche Felder es denn so gibt. PS: Mit dem PWideChar wäre ich mir nicht so sicher (ist wohl abhängig -mal wieder- von der Delphiversion). In MSDN sind die Felder als 'LPCTSTR' deklariert, was einem PAnsiChar entspricht, denke ich. |
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
@Dejan Vu:
Zitat:
@Sir Rufo: das ist aber nur dann genau richtig, wenn man nicht dynamische Typen/Funktionen mit statischen vermischt, also z.B. ShFileOperation mit dem _SHFILEOPSTRUCTW-Record aufruft. |
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
Zitat:
|
AW: FastMM Memory Leaks : Lesen und verstehen von Stacktrace
@DeddyH
Ja das sollte schon klar sein und wurde hier ja auch nicht gemacht. Entweder alles automatisch oder alles fest, dann klappt es auch mit dem Nachbarn. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz