Anfängerfrage zu FastMM 4Speicherlecks in einer Zeile

[BAMatze]

Hallo nochmal an alle DP´ler,

noch eine Frage in Ergänzung zu den Posts heute morgen. Versuche gerade die Speicherlecks in meinem Programm mit der Empfehlung zur Verwendung von FastMM zu beseitigen. Jetzt stoße ich hierbei allerdings auf gewisse Widrigkeiten, wo ich mal gern wüsste, wie ich damit umgehen soll.

Ich verwende folgende 2 Funktionen, die ich auch hier in der DP gefunden habe:

Delphi-Quellcode:

function TFestplattenArbeit.DriveExists(DriveByte: Byte): Boolean;
begin
  Result := GetLogicalDrives and (1 shl DriveByte) <> 0; // Diese Zeile auskommentiert verringert die Anzahl der Speicherlecks um 4 Einträge.
end;

procedure TFestplattenArbeit.simpleDriveSearch(var LaufwerkList: TStringList);
var Index: Integer;
begin
  Index := 0;
// Die ursprüngliche "For Index := 0 to 25 do"-Schleife wurde abgeändert, da hier auch mehrer Speicherlecks "anscheinend" drin waren.
  while DriveExists(Index) do
    begin
      LaufwerkList.Add(Chr(Index + Ord('A')) + ':\');
      Inc(Index);
    end;
end;

Gerade bei der DriveExists-Funktion stehe ich jetzt vor einer meiner Meinung nach Zwiespältigen Frage, enthält diese Zeile wirklich 4 Speicherlecks? Sind das eventuell Folgefehler? Wenn ich die Funktionalität der Funktion haben möchte/ brauche, muss ich dann die Speicherlecks akzeptieren?

Ich hoffe jemand kann mir dort etwas Klarheit verschaffen. Ansonsten war der Tip mit FastMM sehr gut, habe somit meine Speicherlecks von anfänglich 105 auf 58 reduzieren können. Dachte mir schon, dass es einige sein würden, aber sicherlich nicht so viele. Eine Abschließende Frage ist eigentlich sollte man ein Programm möglichst immer mit 0 Speicherlecks erzeugen oder ist eine "verhältnismäßige" Anzahl an Speicherlecks/Zeilenanzahl akzeptabel?

Ps.: im Quellcodebeispiel steht einmal ein anscheinend in Anführungsstrichen, dies ist der Fall, da ich keine qualitativ oder quantitative Erkenntnis daraus gewinnen kann, da keine Erfahrung im Umgang mit Speicherlecks bei mir vorhanden ist.

Vielen Dank
BAMatze

[Alaitoc]

Hey,

nunja so auf den ersten Blick würde ich einfach mal sagen das du bei der Schleife Werte in eine Liste packst sie aber nicht wieder freigibst (bei der For-Schleife hat er wahrscheinlich einfach mehrere Items in die Liste eingefügt als bei der While-Schleife) und beim oberen wüßte ich gern was GetLogicalDrives macht...kann es vll sein das dort die Memoryleaks entstehen?

PS: Also bei mir in der Firma ist es sozusagen Pflicht keine MemoryLeaks zu haben...es ist ja auch kein allzu großer Aufwand den Speicher freizugeben :wink:

MfG Alaitoc

[Blup]

Es gibt eigentlich keine aktzeptable Anzahl von Speicherlecks (schon garnicht Speicherlecks/Zeilenanzahl).
Speicherlecks deren Ursache in fremden Komponenten liegt (oder Delphi-intern), lassen sich manchmal nicht verhindern.
Solange die Größe der Lecks wärend der Programmausführung nicht ständig wächst, kann man damit leben.

In deinem Fall dürfte die Ursache aber nicht die Funktion GetLogicalDrives sein.
Vermutlich gibst du einfach die Variable LaufwerkList irgendwo nicht frei.
Für jeden Laufwerksbuchstaben wird ein eigener String mit eigenem Speicher erzeugt.

Deine While-Schleife bricht wahrscheinlich bereits bei "B:\" ab.
Die For-Schleife prüft alle Buchstaben, entsprechend mehr Einträge hat die Liste.

Mist zu langsam :mrgreen:

[DeddyH]

Wenn Du die Zeile in DriveExists auskommentierst, ist das Result undefiniert. Anscheinend kommt da false bei heraus, so dass die Schleife in simpleDriveSearch nicht durchlaufen wird. Das bedeutet, dass DriveExists nicht die Ursache ist.

[BAMatze]

Danke schonmal für die Anregungen :), allerdings die Liste wird freigegeben, der Fehler ist schon einer der 47 anderen Lecks, die ich behoben hab. Werde mir das ganze wohl übers Wochenende nochmal genauer anschauen müssen.
Wie gesagt, ist gerade jetzt am Anfang schonmal schwer, für die oben genannten Fragen eine Antwort zu finden. Werde hier dann natürlich auch versuchen die Lecks zu stopfen :-D .

Schönes Wochenende
BAMatze

[BAMatze]

Hallo nochmal an alle,

Hab mal noch eine Frage zur Speicherleck-Suche mit FastMM. Hoffe ich verstoße damit nicht gegen die DP-Regeln, da sie eigentlich direkt mit den vorherigen Fragen zusammen hängt, wenn doch mache ich dafür auf Hinweis natürlich noch einen Extrathreat auf.
Also ich habe mir jetzt eigentlich gedacht, da ich ca 10 Units und 4-5 eigene Komponenten für mein Projekt habe und auch in anderen Threats schon gelesen hab, dass das suchen einiger Memorylecks nur mit "Try and Error" zu finden sind (vor allem habe ich AnsiStringErrors welche ja schwer zu lokalisieren sind).
Ich wollte jetzt eigentlich um die Fehlerzahl und Suche zu vereinfachen ein kompeltt neues Projekt auf machen, wo ich jeweils nur 1 Teil meines Hauptprogrammes testen will (also eine Unit oder eine Komponente) und dort auch mit FastMM die Speicherlecks anzeigen lassen. Allerdings stellt sich mir dann jetzt die Frage, ob ich meine Komponenten wirklich so auf Fehler untersuchen kann.
Also die direkte Frage ist, wenn ich eine eigene Komponente (ist direkt in Delphi eingebunden/ installiert) in einem leeren Projekt mit FastMM starte, zeig mir FastMM dann Fehler in der Komponente an?

Vielen Dank
BAMatze

[jaenicke]

Zitat:

Zitat von BAMatze

Also die direkte Frage ist, wenn ich eine eigene Komponente (ist direkt in Delphi eingebunden/ installiert) in einem leeren Projekt mit FastMM starte, zeig mir FastMM dann Fehler in der Komponente an?

Sofern dabei die Funktion, in der das Leck auftritt, benutzt wird, ja. Wenn du da zusätzliche Funktionen hast, die so nie aufgerufen werden, dann werden Speicherlecks darin auch nicht sichtbar.

[BAMatze]

Zitat:

Zitat von jaenicke

Sofern dabei die Funktion, in der das Leck auftritt, benutzt wird, ja. Wenn du da zusätzliche Funktionen hast, die so nie aufgerufen werden, dann werden Speicherlecks darin auch nicht sichtbar.

Gibt es da eventuell Möglichkeiten solche Speicherlecks trotzdem sichtbar zu machen? Denke da z.B. daran, den Quellcode für die Komponente noch einmal in eine Unit zu packen und die Klasse dann dynamisch erzeugen zu lassen in einer Form. Könnte das eventuell dazu führen, dass die Speicherlecks offengelegt werden?

[jaenicke]

Zitat:

Zitat von BAMatze

Denke da z.B. daran, den Quellcode für die Komponente noch einmal in eine Unit zu packen

Eine eigene Klasse gehört normalerweise ohnehin in eine eigene Unit, es sei denn es handelt sich nur um Hilfsklassen. Dann kannst du auch einfach die realen Units einbinden.

Zitat:

Zitat von BAMatze

und die Klasse dann dynamisch erzeugen zu lassen in einer Form. Könnte das eventuell dazu führen, dass die Speicherlecks offengelegt werden?

Das hat nichts damit zu tun ob die Klasse dynamisch erstellt wird oder auf dem Formular liegt.

Beispiel:
Wenn das Speicherleck in einem Setter für eine neue Eigenschaft ist, dann muss die Eigenschaft beim Test auch benutzt werden, damit der Fehler auftritt.

[BAMatze]

Ah ok dann habe ich das jetzt also verstanden, glaube ich. Werde ich also versuchen umzusetzen.

Zitat:

Zitat von jaenicke

Eine eigene Klasse gehört normalerweise ohnehin in eine eigene Unit, es sei denn es handelt sich nur um Hilfsklassen. Dann kannst du auch einfach die realen Units einbinden.

Also genau das versuche ich gerade umzusetzen. Habe vor ca 11-12 Jahren in der Schule TP 2Jahre gelernt (und hatten auch einen sehr guten Lehrer wie ich finde). Allerdings entspricht die Beta-Version, des Programmes an dem ich gerade schreibe (die Beta-Version ist auch Funktionstüchtig), nicht im kleinsten Ansatz den heutigen Standard (dies führt auch zu erheblichen Nebenpüroblemen, wie z.B. erschwerte Fehlersuche, ...). Ich habe an sich nur die Funktionalität der Beta-Version übernommen (teilweise die Steuerung für die Perepherie-Geräte) und versuche die 1.Version (die gerade in Arbeit ist) der OOP anzupassen. Der Unterschied besteht schonmal darin, die Beta-Version hatte eine einzige Form, in der eigentlich alles "reinprogrammiert" war und 3-4 Hilfsformen (Fehlermeldungen) und die jetzige hat über 10 Units mit 3 Komponenten (also Komponenten für diese Aufgabe). Also unterm Strich ist/ war die Beta-Version nicht ansatzweise Stand der Technik von heute. Dies versuche ich gerade in Eigenstudium von Delphi und OOP einigermaßen anzupassen in der Art und Weise, wie du es genannt hast. Ergibt natürlich eine ganz neue Erweiterung an Wissen und viele Fragen :-D .

BAMatze