Memory Leak/ was vergessen?

[nebukadnezzar]

Wie kann ich testen ob ich in meiner App einen Memory Leak habe bzw.
irgendwo vergessen habe ein Objekt vor dem Beenden Frei zu geben oä

[Luckie]

Das geht mit einem Profiler. Mir fällt nur im Moment keiner ein.

[Christian Seehase]

Moin Nebukadnezzar,

mir fällt gerade ein Tool ein: MemProof.

[nebukadnezzar]

Wie gehe ich denn damit um?
wie bekomme ich raus was an den adressen liegt?
und woran erkenne ich nur die vergessenen FreeMem?

ausserdem bekomme ich auch fehler aus Dephi Proceduren!

[Christian Seehase]

Moin Nebukadnezzar,

tut mir leid, da kann ich Dir nicht weiterhelfen.
Ich kenne das Tool nur dem Namen nach, und habe noch nie damit etwas gemacht.

[Hansa]

Zitat:

Zitat von Luckie

Das geht mit einem Profiler. Mir fällt nur im Moment keiner ein.

Luckie: wo ist Dein Gedächtnis nur hin ? :mrgreen:

[Leuselator]

@Hansa: schau mal auf den Thread-Titel - dämmerts? :mrgreen:

[Hansa]

:shock: :shock: :shock: Leuselator, Du willst doch hoffentlich nicht behaupten, Luckie hätte ein Memory Leak :mrgreen:

hier drum geht es :

http://www.delphipraxis.net/internal...b07e82a24c8ad5

eigentlich aber hier drum:

http://www.delphipraxis.net/internal...133&highlight=

[jbg]

Zitat:

Zitat von Hansa

Zitat:

Zitat von Luckie

Das geht mit einem Profiler. Mir fällt nur im Moment keiner ein.

Luckie: wo ist Dein Gedächtnis nur hin ? :mrgreen:

Und ich frage mich, was ein Profiler mit einem Memory Leak Such-Programm zu tun hat.

[Luckie]

Heißen die Dinger nicht so?

[Hansa]

Zitat:

Zitat von jbg

Und ich frage mich, was ein Profiler mit einem Memory Leak Such-Programm zu tun hat.

Der Gedanke ist nicht von der Hand zu weisen. Aber nicht sofort zu erkennen. Ich habe eine Testreihe gebaut, so eine Art eigener Profiler. Sobald ich den starte und zwar so :

Delphi-Quellcode:

procedure TfrmHauptmenue.Button1Click(Sender: TObject);
var i : integer;
begin
 i := 1;
 repeat
   i := i + 1;
   lblClick(Sender);   // created frm
if i mod 100 = 0 then
memo1.Lines.Add (IntToStr (i)+'  '+SysUtils.TimeToStr (time));
    close;
//    frm.Free;
  until i = 0;
end;

erhalte ich folgendes Ergebnis:

so wie es hier steht, steigert sich die Zeit um 100 Forms zu erzeugen exponentiell. Die ersten hundert brauchen 4 sec. die nächsten 8, dann 16 usw. Ist das free nicht auskommentiert, so läuft es linear alle 4 sek. 100 forms. Irgendwo wird da also schon wahrscheinlich was verbrutzelt und ist wegen meines obligatorisch überdimensionierten Gates-Speicher nicht so einfach zu sehen. Weiter bin ich damit aber jetzt auch nicht. Interessant wäre es, den tatsächlich beanspruchten Speicher zu sehen.

[d3g]

Zitat:

Zitat von Hansa

Delphi-Quellcode:

i := 1;
repeat
   i := i + 1;
   // ...
until i = 0;

4,3e9 Formulare? :shock:

[Hansa]

ist doch ziemlich klar, was ich da mache, oder ?

[d3g]

Ich finde nur die Anzahl der Formulare, die erzeugt werden, ein bisschen übertrieben (mal abgesehen davon, dass du ziemliche Probleme bekommen solltest, wenn der Integer mal 64 bit lang wird)...

Den Zusammenhang zwischen Profiling und Memory Leak Checking, den du aufzeigst, kann man sowieso nicht ausnutzen -- wer sagt, dass der immer besteht? Im Übrigen arbeiten diese beiden Programme auch komplett unterschiedlich. Ein Profiler hängt sich wie ein Debugger an den Prozess an und macht permanente Stack Traces, ein Memory Leak Checker funktioniert AFAIK über API-Hooking.

[Hansa]

Ich teste lieber selber etwas, bevor ich ein fertiges (oder unfertiges :?:) Programm benutze und nicht weiß, was das genau macht. Aber das gehört in die Kategorie: "Wer weiß, wo es eine Komponente gibt, die genau das macht, was ich mir ersparen will ?" 8) und nicht hier her.