FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[Dejan Vu]

Zitat von taveuni:

@Dejan Vu: Keine Ahnung wie Du das meinst. pFrom und pTo sind Variablen eines Records. Was soll man da komplett(er) belegen?

Wie wäre es damit, *alle* Felder des Records explizit mit definierten Werten zu belegen? Wo werden denn im Code die Felder Wnd, fAnyOperationsAborted, hNameMappings und lpszProgressTitle gesetzt? Letzteres muss man wohl bei deiner Konstellation nicht belegen, aber unsauber ist es schon, da bei Änderung der Parmeter der Title doch eine Rolle spielen könnte. Nicht in diesem Kontext, aber bei Copy&Paste spielt das schon eine Rolle. Und das das negative Folgen haben kann, einige Werte undefiniert zu lassen, hat man ja wohl gesehen.

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.

[DeddyH]

@Dejan Vu:

Zitat:

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

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

@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.

[taveuni]

Zitat von DeddyH:

Zitat:

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?

[Sir Rufo]

Zitat von taveuni:

Zitat von DeddyH:

Zitat:

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 von Sir Rufo:

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?

[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!"

[Sir Rufo]

@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.

[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

[baumina]

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

  sh := Default(TSHFileOpStruct);

[Dejan Vu]

Zitat von baumina:

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

  sh := Default(TSHFileOpStruct);

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