Windows-Taskmanager enthüllt unerklärliche Speichergier

Hanz · Verfasst: So 13.11.05 05:42

Ein größeres Datenbank-Projekt beinhaltet einen Ausdrucksparser (der also numerische Ausdrücke wie x^2+100/6 erkennen kann, einschließlich von Symbolen und Stringverarbeitung). Der Parser ist ein nicht visuelles Objekt (ohne form und alles), der neben den Datenstrukturen die Funktionen des Parsers enthält, also Scannen, Parsen, Baum aufbauen, Baum abarbeiten, Baum wieder zerstören. Nicht triviale, aber sehr bodenständige Programmierung.

Die Speicherverwaltung ist natürlich dynamisch, da der Parser sich durch die Formel frißt und einen Ereignisbaum aufbaut, der dann bei der Abarbeitung rekursiv abgearbeitet wird. Speicher wird via getmem beantragt und freemem freigegeben; diese Proceduren sind allerdings gekapselt, um (1) Fehler abzufangen zu können, und (2) optional zu Testzwecken in ein Logfile schreiben, ob eventuell irgendwo Speicher beantragt, aber nicht freigegeben wurde.

Dieser Parser liegt 'unterhalb' eines Datenbankinterpreters. Wenn nun der Datenbankinterpreter z.B. einen Befehl bekommt wie
MOV betrag,x*1.16 (tue x*1.16 nach 'betrag')
schaut er nach, ob 'betrag' eine gültige Variable (oder ein Datenfeld) ist und löst mit Hilfe des Parsers den rechts stehenden Ausdruck auf. Dazu wird ein Parserobjekt dynamisch erzeugt, also via [gekapseltem] getmem(pPa,ParserObject). Dann wird fröhlich mit pPa der Ausdruck aufgelöst, der Ereignisbaum aufgebaut, eventuell mehrfach im Laufe des Interpreterprogramms abgearbeitet und am Ende freigegeben. Die Freigabe geschieht mit einem destructor, der allen vom Parser selber beantragten Speicher freigibt, und dann selbst via freemem(pPa,ParserObject) entfernt wird.
Das funktioniert auch alles fabelhaft (und zwar seit Jahren), aber nun habe ich festgestellt, dass dem guten Parser bei jedem Aufbau des Parserbaums etwa 16KB verloren gehen. Ich sehe das nur im Windows-Taskmanager, wo sich bei einem komplexen Programm des Interpreters der vom Programm belegte Speicher rasend schnell erhöht. Detailtest zeigen mir dann, dass an dem Punkt, wo der Parser ein array von ca 64 KB freigeben soll (via freemem), nur 48 KB bei Windows wieder ankommen; 16 KB verschwinden.
Ich mußte das alles so genau erklären, um klar zu machen, dass ich nicht irgendwo 'vergessen' habe, Speicher wieder freizugeben. Wie gesagt, getmem und freemem sind gekapselt und können überwacht werden (man kennt das ja bei großen Projekten).
Als Systemprogrammierer würde ich sagen, dass die Garbage-collection ein bißchen buggy ist, aber das kann doch wohl nicht sein, oder ? Der Parser hantiert auch mit long-strings, kann das eine Ursacher sein ? Muss ich das Objekt, dass ich mit einem schlichten [gekapselten] getmem initialisiere (und mit freemem wieder freigebe) noch irgendwie anders ins Nirwana schicken ?
Ich arbeite mit Delphi 4.0 und danke für jeden Hinweis.
Hanz

Horst_H · Verfasst: So 13.11.05 10:42

Hallo,

ich habe bei mir schon merkwurdigen Speicherverbrauch bei exzessiver Stringverarbeitung dadurch in den Griff bekommen, das ich das Ergebnis nicht ueber eine Funktion sondern als Referenzparameter einer Prozedur uebergeben habe.
Bei manchen habe ich auch solche Konstrukte gesehen.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

procedure EVA(var ioStr:string);
var 
  strTemp: string;
begin
  strTemp := iostr;
  arbeite mit strTemp;
  iostr := strTemp;
  strTemp:= '';//strTemp explizit freigeben damit ist hoffentlich iostr ein unique string
end;

Gruss Horst

Hanz · Verfasst: Mo 14.11.05 00:29 Titel: String ist Schuld?

Danke, Horst, dass der Fehler in diesem Bereich liegt, habe ich auch vermutet.
Ja, der Parser erhält natürlich den Ausdruck in einem string, der dann aber via

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:

function parsen(var ausdruck : string) : integer;
var ps : ^string;
begin
ps:=@ausdruck;
... mit ps arbeiten

auch umgangen wird, aber offenbar nicht sauber freigegeben wird. Ich werde versuchen, das jetzt eleganter zu lösen und hier noch einmal berichten.
Danke erst einmal.

Moderiert von raziel: Delphi-Tags hinzugefügt.

Hanz · Verfasst: Di 15.11.05 03:29 Titel: Problem gelöst

Ich habe den Code enstprechend den Hinweisen von Horst verwendet und konnte das Problem damit beseitigen. Wenn longstrings am Ende einer Funktion/Prozedur bzw. innerhalb eines Objekts nicht ordnungsgemäß geleert werde, belegen sie offenbar weiterhin Speicherplatz.
An Horst noch einmal herzlichen Dank.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme