[FastMM] Woher kommt UnicodeString Speicherleak?

[s.h.a.r.k]

Hallo zusammen,

seit geraumer Zeit setze ich FastMM ein, um Speicherleaks zu finden. Alle groben Fehler lassen sich damit ja prima aufdecken, nur habe ich zurzeit immer wieder Probleme mit UnicodeStrings. Im Moment sind es circa 20 Stellen, an denen scheinbar ein Speicherleak auftritt, nur wie kann ich diese finden? Ebenso interessant wäre es, woher diese kommen können!? Selbst alloziiere ich keinerlei Speicher für Strings, d.h. ich nutze nur var TmpStr: String;.

[ele]

Mir sind keine Probleme bezüglich Memory-Leaks und UnicodeStrings bekannt. Wenn du ein Testprojekt zusammenstellen kannst wo das Problem auftritt, könnte man vielleicht weiterhelfen.

[s.h.a.r.k]

Das Projekt selbst ist verdammt groß und ich nutze zudem auch Fremdkomponenten, d.h. das erschwert die Sache ungemein. Vielleichts gibt es ja eine Art Allheilmittel für sowas...

[rollstuhlfahrer]

nein, Allheilmittel gibt es keine. Aber Windows räumt nach dem Beenden des Prozesses kräftig auf, sodass auch alle Speicherlecks am Ende wieder weg sind. Problematisch wirds nur, wenn das Speicherleck häufig auftritt und das Programm mehr als 24h am Stück laufen wird. Dann kommt selbst der Windows-eigene Aufräummechanismus nicht zum tragen, weil der Prozess ja noch läuft und es sich immer mehr unerwünschter Müll ansammelt.

Bernhard

[jbg]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027430)

Ebenso interessant wäre es, woher diese kommen können!?

Da wären z.B. Records mit String-Feldern, die im VirtualTreeView eingesetzt werden. Wenn man da vergisst Finalize() im OnFreeNode aufzurufen, bleiben die Strings im Speicher liegen, wenn der Record vom Tree freigegeben wird.

Auch problematisch sind threadvar-strings. Denn es gibt keinen Punkt im Code an dem man alle auf einmal auf '' zurücksetzen kann.

[himitsu]

Das Windows am Ende vieles aufräumt (Aufgrund der getrennten Speicherberecher seit WinNT gut machbar) ist ja gut, aber dennoch sollte man nicht Schludern und möglichst aufräumen.

Ein böses Beispiel:
Du nutzt seit Jahren einen Code, welcher ein bekanntes und absichtlich ignoriertes Speicherleck besitzt. (machte ja keine Probleme ... Windows räumt schon auf)
Aber nun willst du diesen Code öfters in einem langzeitlaufenden Programm nutzen und peng.

[s.h.a.r.k]

Also sauber aufräumen will ich auf jeden Fall, weil das allein schon zu einem sauberen Programmierstil gehört. Mir geht das übelst gegen den Strich wenn eine Anwendung immer mehr Ressourcen frisst, wozu denn auch?! Nur weil der Programmierer eigentlich zu faul war.

@jbg: was verstehst du unter threadvar-strings.? Public String-Variablen in einer Thread-Klasse?

[himitsu]

threadvar

PS: Hat jemand einen einfachen StackTrace-Code?
Dann könnte ich eine einfachen LeckSuchCode zusammenstellen.

Nur die letzte Aufrufstelle, welche den Speicher letzendlich reserviert hatte, sagt oftmals ja nicht viel aus.

[jbg]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1027458)

@jbg: was verstehst du unter threadvar-strings.?

Delphi-Quellcode:

threadvar
  MyString: string;

Jeder Thread hat dabei seine eigene string-Variable. Und das ist nicht nur auf TThread Instanzen beschränkt.

[s.h.a.r.k]

Ich glaube ich hab den Fehler gefunden. Und zwar gibt es ja in der FastMM-Datei FastMM4Options.inc die Option FullDebugMode. Wenn ich diese Option aktiviere, so erzeugt FastMM je UnicodeString-Speicherleak einen Eintrag in die Datei . Hier ein Auszug:

Code:

--------------------------------2010/6/9 19:18:55--------------------------------
A memory block has been leaked. The size is: 68

This block was allocated by thread 0x14B0, and the stack trace (return addresses) at the time was:
411ABA 
404837 
4084EE 
4085A5 
70CAE4 
710269 
7A4B47 
7A5238 
4C1B29 
48DC4F 
48E6B5 

The block is currently used for an object of class: UnicodeString

The allocation number is: 13604998

Current memory dump of 256 bytes starting at pointer address 7E7E5630:
B0 04 02 00 01 00 00 00 17 00 00 00 38 00 37 00 30 00 20 00 44 00 61 00 74 00 65 00 6E 00 73 00
E4 00 74 00 7A 00 65 00 20 00 67 00 65 00 66 00 75 00 6E 00 64 00 65 00 6E 00 00 00 19 2D CB 78
80 80 80 80 80 80 80 80 00 00 00 00 A0 18 7E 7E 00 00 00 00 00 00 00 00 44 18 41 00 00 00 00 00
58 B3 D3 00 BA 1A 41 00 37 48 40 00 EE 84 40 00 A5 85 40 00 E4 CA 70 00 69 02 71 00 47 4B 7A 00
38 52 7A 00 29 1B 4C 00 4F DC 48 00 B5 E6 48 00 B0 14 00 00 16 48 40 00 F0 9E 40 00 27 D8 51 00
94 D3 51 00 6F 28 53 00 C9 2F 53 00 2C 07 71 00 BC CB 70 00 69 02 71 00 47 4B 7A 00 38 52 7A 00
B0 14 00 00 3A 00 00 00 00 00 00 00 FC 5F 5C 87 B0 04 02 00 01 00 00 00 16 00 00 00 38 00 32 00
20 00 44 00 61 00 74 00 65 00 6E 00 73 00 E4 00 74 00 7A 00 65 00 20 00 67 00 65 00 66 00 75 00
°  .  .  .  .  .  .  .  .  .  .  .  8  .  7  .  0  .     .  D  .  a  .  t  .  e  .  n  .  s  .
ä  .  t  .  z  .  e  .     .  g  .  e  .  f  .  u  .  n  .  d  .  e  .  n  .  .  .  .  -  Ë  x
€  €  €  €  €  €  €  €  .  .  .  .  *  .  ~  ~  .  .  .  .  .  .  .  .  D  .  A  .  .  .  .  .
X  ³  Ó  .  º  .  A  .  7  H  @  .  î  „  @  .  ¥  …  @  .  ä  Ê  p  .  i  .  q  .  G  K  z  .
8  R  z  .  )  .  L  .  O  Ü  H  .  µ  æ  H  .  °  .  .  .  .  H  @  .  ð  ž  @  .  '  Ø  Q  .
”  Ó  Q  .  o  (  S  .  É  /  S  .  ,  .  q  .  ¼  Ë  p  .  i  .  q  .  G  K  z  .  8  R  z  .
°  .  .  .  :  .  .  .  .  .  .  .  ü  _  \  ‡  °  .  .  .  .  .  .  .  .  .  .  .  8  .  2  .
   .  D  .  a  .  t  .  e  .  n  .  s  .  ä  .  t  .  z  .  e  .     .  g  .  e  .  f  .  u  .

Bisher habe ich noch nie auf das, was unter den Hexzahlen steht. Aber da steht ja sehr genau, wo das Problem liegt :) Der String, der auch hier zu lesen ist, kann ich nachverfolgen und bin somit auf das Log-Modul gestoßen, welches der Schuldige war *grml*