Programm belegt immer mehr Speicher

[TheMiller]

Hallo,

in anderen Threads habe ich ja eine Lösung gesucht und jetzt auch eingebaut, PlugIns nach der Benutzung wieder freizugeben. Diese PlugIns sind DLL-Forms. Beim Laden speicher ich in ein Array den Titel, das Handle und den Pfad zur DLL. Wenn ich die DLL lade, wird der Hauptprozess im Speicher um ca 2MB größer. Soweit ist das auch ok. Wenn ich das PlugIn wieder entlade, schrumpft das Programm nicht auf seine ursprüngliche Größe, sondern es bleibt 200kb größer. Öffne ich das PlugIn nochmal, wird es wieder um 160kb größer. Beim nächsten Öffen und Schließen des PlugIns wird der Hauptprozess um 80kb größer usw... d.h, das Programm wird ständig um eine kleiner werdene Größe größer (Der Satz gefällt mir).

Woran kann sowas liegen?

[Bernhard Geyer]

Ein kleiner Teil davon liegt an einem Fehler in Delphi das DLL's nicht wirklich 100%ig entladen werden. Müsste auch irgendwo in QC oder DN-Seite bei Codegear beschrieben sein.

[TheMiller]

Wie groß ist ungefähr ein kleiner Teil? Werden diese nicht genutzten Speicheblöcke (?) von Windows nach einer gewissen Zeit wieder freigegeben, also sozusagen: Räumt Windows den Speicher selbst wieder auf?

[hoika]

Hallo,

wie sieht es denn aus mit fastmm oder memcheck ?
Hast du damit mal nach Lecks gesucht ?


Heiko

[TheMiller]

Davor hab ich immer Angst

Ne, das ist eine gute Idee. Das kann ich mal machen. Aber das eine PlugIn, mit dem ich das getestet habe, hat nur ein INI-Object und einmal die ZQuery und ZConnection... Mal sehen.

[TheMiller]

Hm...

wie kann ich denn mein PlugIn mit FastMM4 prüfen? Ich hab die Unit in die Projekt-Unit (erste Unit) eingebunden und er zeigt mir KEINE Fehler an, obwohl ich einen eingebaut habe. Im Hauptprogramm funktioniert die Fehlerprüfung (war nur einer!!!). Doch die DLLs werden ja vom Programm ge- und entladen. Muss ich noch was spezielles einstellen?

[TheMiller]

Kann es auch sein, dass die erstellten Forms in der DLL nicht richtig freigegeben werden? Ich mache das so:

Delphi-Quellcode:

PlugInName.FreeForms;
FreeLibrary(DLLHandle);

//In der DLL:
procedure TMeinPlugIn.CreateForms;
begin
  Form1:=TForm1.Create(nil);
end;

procedure TMeinPlugIn.FreeForms;
begin
  FreeAndNil(Form1);
end;

Ist das richtig?

[hoika]

Hallo,

bei memcheck gibt es einen Aufruf (meminit),
den packst du in die library unit
über

begin
Meminit // oder so ähnlich
end;

[TheMiller]

Hallo,

ich habe MemCheck eingebeunden. Er findet SpeicherLecks in FindUtils.pas und bricht dann mein ganzes Projekt ab. Ist das richtig? Es kommt eine AV, dann die Log-File von MemCheck und dann wird mein Programm beendet. Hier mal die Log:

Zitat:

MemCheck version 2.75

TOP 10 Leaks: begin
Leak #0 User allocated memory (GetMem)
Size: 100
1 Occurence
call stack - 0 : (no debug info) Find error: 0012F544
call stack - 1 : Module sysutils.pas Routine @Sysutils@Exception@CreateFmt Line 13258 Find error: 0040E799
call stack - 2 : Module sysutils.pas Routine CreateAVObject Line 13640 Find error: 0040EDB3
call stack - 3 : Module sysutils.pas(no debug info) Line 13654 Find error: 0040EEC1
call stack - 4 : Routine @System@@ExceptionHandler Find error: 004048EE
call stack - 5 : (no debug info) Find error: 77711007
call stack - 6 : (no debug info) Find error: 77710E93

Leak #1 User allocated memory (GetMem)
Size: 16
1 Occurence
call stack - 0 : (no debug info) Find error: 0012F6A4
call stack - 1 : Module sysutils.pas(no debug info) Line 13654 Find error: 0040EEC1
call stack - 2 : Routine @System@@ExceptionHandler Find error: 004048EE
call stack - 3 : (no debug info) Find error: 77711007
call stack - 4 : (no debug info) Find error: 77710E93

TOP 10 Leaks: end

Total leak: 116 bytes


*** MEMCHK: Blocks STILL allocated ***

Leak #0 User allocated memory (GetMem)
Size: 100
1 Occurence
call stack - 0 : (no debug info) Find error: 0012F544
call stack - 1 : Module sysutils.pas Routine @Sysutils@Exception@CreateFmt Line 13258 Find error: 0040E799
call stack - 2 : Module sysutils.pas Routine CreateAVObject Line 13640 Find error: 0040EDB3
call stack - 3 : Module sysutils.pas(no debug info) Line 13654 Find error: 0040EEC1
call stack - 4 : Routine @System@@ExceptionHandler Find error: 004048EE
call stack - 5 : (no debug info) Find error: 77711007
call stack - 6 : (no debug info) Find error: 77710E93

Leak #1 User allocated memory (GetMem)
Size: 16
1 Occurence
call stack - 0 : (no debug info) Find error: 0012F6A4
call stack - 1 : Module sysutils.pas(no debug info) Line 13654 Find error: 0040EEC1
call stack - 2 : Routine @System@@ExceptionHandler Find error: 004048EE
call stack - 3 : (no debug info) Find error: 77711007
call stack - 4 : (no debug info) Find error: 77710E93

*** MEMCHK: End of allocated blocks ***


*** MEMCHK: Chronological leak information ***

* User allocated memory (GetMem) (Leak #1) Size: 16
* User allocated memory (GetMem) (Leak #0) Size: 100

*** MEMCHK: End of chronological leak information ***


*** MEMCHK: Blocks written to after destruction ***

Bad blocks count: 0


*** MEMCHK: End of blocks written to after destruction ***

[hoika]

Hallo,

das ist jetzt mal ein "Nebeneffekt",
durch die Schutzverletzung wird Exception-Speicher nicht freigegeben.

Die Schutzverletzung weist auf einen Fehler bei dir im Speicher-Management hin.
Der Memcheck-Memory-Manager ersetzt ja den internen von Codegear,
und der ist pingeliger als der alte.
Die Schutzverletzung muss natürlich raus ..

Wenn du memcheck in der IDE laufen lässt und ein "normales" speicherleck
gefunden wird, wirdnach dem Programmende über eine Exeption genau an
die Stelle gesprungen, wo der Speicher erzeugt wird, also
z.B. myObject:= TObject.Create;

Ist manchmal ganz sinnvoll, ich unterbreche das dann aber über Strl+F2.
Dann wird das Log direkt angezeigt (wie du hier gerade siehst).


Heiko