FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[DeddyH]

Richtig, ich hatte mich auch von dem _SHFILEOPSTRUCTW irritieren lassen, aber der wird ja gar nicht explizit benutzt. Trotzdem schön, dass wir mal drüber gesprochen haben ;)

[Sir Rufo]

Zitat:

Zitat von taveuni (Beitrag 1272702)

Zitat:

Zitat von DeddyH (Beitrag 1272700)

Zitat:

Delphi-Quellcode:

FillChar(sh,SizeOf(sh),0);

Damit wird der komplette Record mit Nullen befüllt, was soll er denn noch machen?

Das habe ich (eigentlich wars nicht ich) aber eben vorher genau nicht gemacht! Und da ist dann das Memory gestiegen. Mit dem FillChar nicht mehr. Meine Frage ist nun: Weshalb muss das gemacht werden? Und: Muss dass in Delphi eigenen Funktionen wo Records (notabene als const) übergeben werden ebenfalls gemacht werden?

Du hast aber auch nicht alle Felder des Records belegt und da der lokal definiert ist kann da irgendein Müll noch enthalten sein, speziell bei den Pointern.

[taveuni]

Zitat:

Zitat von Sir Rufo (Beitrag 1272706)

Du hast aber auch nicht alle Felder des Records belegt und da der lokal definiert ist kann da irgendein Müll noch enthalten sein, speziell bei den Pointern.

Und was sagt mir das bezüglich Memory Leak bei nicht verwenden von Fillchar oder/und nicht belegen aller Felder des Records usw. in Verbindung mit der Funktion und dem Record? Also: wie mach ichs richtig? Vor allem: Weshalb entsteht das MemoryLeak hier?

[Dejan Vu]

Gut, das ich verstanden werde. Endlich. Nach all den Jahren.

Zitat:

Zitat von taveuni (Beitrag 1272702)

Meine Frage ist nun: Weshalb muss das gemacht werden?

Weil so gut wie jedes Feld eine Rolle spielt bzw. sich die Verwendung aus der Doku meistens ableiten lässt. Und -banal blöde Antwort- weil wir ein deterministisches Verhalten wollen und das geht nur mit deterministischen Eingabewerten. Ein Record als lokale Variable ist bezüglich ihres Inhaltes nicht deterministisch. FillChar bügelt erstmal Nullen drübber, damit wird es nicht unbedingt richtig, ist aber meist sicher (nullstrings, alles auf 'false', keine Optionen etc.).

Bemängelt habe ich an dem Bügeln und Setzen einzelner Felder (genau denen, die man gerade benötigt) nur die fehlende Codedokumentation. Mit meiner Vorgehensweise (die eigentlich aus der Faulheit heraus geboren ist), habe ich alle Felder parat und kann mich nicht mehr herausreden.

Zitat:

Zitat von taveuni (Beitrag 1272708)

Und was sagt mir das bezüglich Memory Leak bei nicht verwenden von Fillchar oder/und nicht belegen aller Felder des Records usw. in Verbindung mit der Funktion und dem Record? Also: wie mach ichs richtig? Vor allem: Weshalb entsteht das MemoryLeak hier?

Eben 'nicht deterministisches Verhalten'. Mich wundert das auch (das Speicherleck), aber Du hast den Beleg dafür und ohne Quellcode der Shell bringt es nichts. Das Vorgehen deines Kollegen war nachlässig und Du durftest das ausbaden. Vielleicht ist es ein kleiner Bug in der Shell, der für Exploits (was ihr da gemacht habt, geht ja in die Richtung) ausgenutzt werden kann. Wer weiss.

[Sir Rufo]

Für die genaue Ursache wirst du wohl MS fragen müssen. Vermutlich sagen die dann "Gib uns vernünftige Daten und wir reagieren vernünftig!" ;)

[baumina]

Ich habe hier ja kürzlich gelernt, dass man statt FillChar Default nutzen sollte, weils sicherer (zumindest was managed types angeht) ist.

Delphi-Quellcode:

  sh := Default(TSHFileOpStruct);

[Dejan Vu]

Zitat:

Zitat von baumina (Beitrag 1272715)

Ich habe hier ja kürzlich gelernt, dass man statt FillChar Default nutzen sollte, weils sicherer (zumindest was managed types angeht) ist.

Delphi-Quellcode:

  sh := Default(TSHFileOpStruct);

Eigentlich richtig und ein sehr guter Tipp. Aber managed Types (Strings z.B.) haben wir hier nicht.

[taveuni]

Zitat:

Zitat von baumina (Beitrag 1272715)

Ich habe hier ja kürzlich gelernt, dass man statt FillChar Default nutzen sollte, weils sicherer (zumindest was managed types angeht) ist.

Delphi-Quellcode:

  sh := Default(TSHFileOpStruct);

Oh! Ist das ein Easteregg im Compiler? Da findet sich ja überhaupt nichts im Internet darüber. Ich musste den Google Cache bemühen um überhaupt was zu finden.

Frage: Can anyone point to documentation on it?
Antwort: There isn't any.
:coder2:

[Der schöne Günther]

Default bin ich auch nur drüber gestolpert, Doku nie gefunden :-(

Auch: Wie hast du eigentlich nun diese Stelle gefunden?

[DeddyH]

Über den Google Cache, hat er ja oben verlinkt ;)

[taveuni]

Zitat:

Zitat von Der schöne Günther (Beitrag 1272724)

Auch: Wie hast du eigentlich nun diese Stelle gefunden?

Falls Du die Stelle im Code meinst: Fakt war: Während der Laufzeit mit FastMM oder DDDebug war nichts sichtbar aber der Memoryverbrauch stieg trotzdem. Somit war klar dass es sich (laut Zacherl's Tipp) um eine "Systemfunktion" handeln muss. Ich hab dann im Code diese Stellen gesucht und diese Funktionen wieder isoliert extrem getestet. Bei der ersten hatte ich Erfolg.