Nein, hab ich nicht. Bekomme ich mit GetProcessMemoryInfo nicht dieselbe Aussage?

Ich habe sicher ein Leck. Ich habe einen zweiten Testthread ins Programm eingebaut und der macht mir keine dauerhafte Vergrößerung des Prozessspeichers.

FastMM ist z.B. so ein Profiler, die ich in deinem anderen Thread-Thread () erwähnt hatte. Und nein, er macht NICHT das selbe. Probier's einfach mal.

Edit: Und wenn alles nix hilft (probier FastMM aber wirklich vorher), zeig uns doch mal den gesamten Code deiner Thread-Klasse.

FastMM ist offenbar ein mächtiges Tool, wenn man es zu nutzen weiß.

Ich habs mal ganz naiv eingebunden und festgestellt, dass nicht nur meine Threadobjekte lecken:

Zitat:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

13 - 20 bytes: TObjectList x 3
21 - 36 bytes: TWinHelpViewer x 1
37 - 52 bytes: THelpManager x 1

Was lerne ich jetzt daraus? Wie kann ich vorgehen um die Lecks zu stopfen?
Übrigens: Ich benutze garkeine Objekte vom Typ TWinHelpViewer bzw. THelpManager in meiner App.

???

P.S.

Die obigen FastMM4 Fehlermeldungen bekomme ich nur, wenn ich meinen Code in der Delphi6PE IDE laufen lasse. Jedes Dummyprojekt erzeugt in der Delphi6PE IDE dieselben Fehler. In der Delphi7PE IDE werden keine solchen Fehler ausgegeben. ????

Für solche aufeinanderfolgende Posts gibt es einen Editbutton, um nicht zu Pushen.
http://www.delphipraxis.net/dpX_faq_...?faq=Q_27#Q_27

Dann sind einige Speicherlecks "Absicht" und Andere ... wie hast du FastMM eingebunden?
Die Unit muß als Allererste in der DPR eingetragen sein.

Ok, werde künftig editieren.

Zitat:

Die Unit muß als Allererste in der DPR eingetragen sein.

Hab ich genau so gemacht. Stand auch so in der Readme. Habe ein LogFile erzeugen lassen.

Die Delphi6 Personal und Delphi7 Personal IDE verhalten sich definitiv unterschiedlich.

P.S.
Jetzt wirds noch besser: in D7 ist auch das Thread-Leck verschwunden. FastMM scheint aber zu funktionieren. Wenn ich das Programm beende, ohne das Thread-Object zu free-en, dann wird ein Speicherleck angezeigt, was ja auch Sinn macht.

Trotzdem zeigt der Prozessspeicher mit jedem neuen Free-Create-Zyklus einen Prozessspeicherzuwachs. Muss mich das nun beunruhigen? Ich beabsichtige den Thread viele tausende Male neu zu starten.

Wenn du die Anzeige im Taskmanager meinst, braucht dich das nicht zu beunruhigen. Der Speichermanager (hier FastMM) weis es besser

Du brauchst übrigens deine dynamischen Variablen (Strings, Arrays) nicht auf Länge 0 setzen, dass passiert automatisch.

Zitat:

Der Speichermanager (hier FastMM) weis es besser

Das ist offenbar wirklich richtig und ziemlich erstaunlich.

Ich habe mal meinen Thread 2 Stunden lang alle Sekunde gestartet, wieder beendet und ge-"free"d und den Prozessspeicher dabei beobachtet. Der wuchs dabei eine Zeit lang in 12k Schritten um insgesamt ca. 700k. Danach stabilisierte der sich aber und wuchs nicht weiter. Man fragt sich dabei warum.

FastMM hat beim Beenden des Programms kein Memoryleck gefunden. Mein Code ist also offenbar ok

Noch eine Frage:
Ist es sinnvoll FastMM dauerhaft eingebunden zu lassen oder sollte man das am Ende der Programmentwicklung wieder rausschmeissen?

Zitat:

Du brauchst übrigens deine dynamischen Variablen (Strings, Arrays) nicht auf Länge 0 setzen, dass passiert automatisch.

Das stimmt auch. FastMM meldet kein Problem, wenn man die Felder nicht wieder auf Länge Null zurücksetzt. Der Prozessspeicher sieht das wiederum anders (Fragmentierungsproblem?)

FastMM versucht etwas zu optimieren,
dabei sucht er z.B. nicht ständig seinen ganzen Speicher nach 'nem freien Platz passender Größe ab, wenn irgendetwas Speicher haben will, sondern er sucht nur ab einer bestimmten Position (ab da wo zuletzt freier Speicher gefunden wurde).
Wenn jetzt etwas freigegeben wird, dann entsteht vor dem gemerkten Positionszeiger eine Lücke, welche zwar in FastMM frei, aber dennoch bei Windows registirert ist.
Nun wird aber erstmal danach gesucht, so daß einige Lücken entstehen, welche Dank der "Optimierung" eine Weile bestehen bleiben, bis irgendwann der Positionszeiger hier wieder vorbeikommt.

> das ist jetzt alles nur "vereinfacht" ausgedrückt.

Also die Suche ist so zwar schneller, aber er braucht etwas mehr Speicher, welchen du hier entdeckt hast.

Zitat:

Noch eine Frage:
Ist es sinnvoll FastMM dauerhaft eingebunden zu lassen oder sollte man das am Ende der Programmentwicklung wieder rausschmeissen?

???