AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi Warum meckert FastMM hier ein Speicherleck an?
Thema durchsuchen
Ansicht
Themen-Optionen

Warum meckert FastMM hier ein Speicherleck an?

Ein Thema von Benmik · begonnen am 19. Dez 2018 · letzter Beitrag vom 21. Dez 2018
Antwort Antwort
Seite 2 von 2     12   
Benmik

Registriert seit: 11. Apr 2009
557 Beiträge
 
Delphi 12 Athens
 
#11

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 19. Dez 2018, 17:41
Das Problem wurde durch hoika gelöst.

Die Stelle, die mir - im Nachhinein gesehen - hätte auffallen müssen, lautet:JamPathList := JamShellLink.SelectionList.GetListOfAllFiles; Dort wird eine TStringList zurückgegeben, die in GetListOfAllFiles erzeugt wird. JamPathList muss/darf also gar nicht erzeugt werden, daher ganz richtig das Speicherleck. Tschuldigung, FastMM!

Meiner Meinung nach ist die Routine ein Verstoß gegen das Gebot, dass Objekte dort freigegeben werden sollen, wo sie auch erzeugt werden. Daher hatte ich nicht damit gerechnet, hätte es aber müssen, denn was soll JamPathList := ... anderes bedeuten? Danke nochmal.
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.275 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 19. Dez 2018, 17:53
Hallo,
sehe ich auch so.
Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.

Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.

Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...
Heiko
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
557 Beiträge
 
Delphi 12 Athens
 
#13

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 19. Dez 2018, 18:20
Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.
Genau!

Interessant auch, wie zielgenau ich exakt diejenige Codezeile, die zur Lösung geführt hätte, als scheinbar (ja, scheinbar, nicht anscheinend!) unwichtig weggelassen hatte.

Auf der anderen Seite wundere ich mich immer, wie hier die Experten einen Fullpost von 500 Zeilen offenbar mit Lichtgeschwindigkeit durchparsen. Wahrscheinlich dauert es nicht mehr lang, bis die Compilerisierung eines Programmiererhirns als Berufskrankheit anerkannt wird.
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.444 Beiträge
 
Delphi 11 Alexandria
 
#14

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 20. Dez 2018, 14:04
Hallo,
Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.
Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...
Es wäre m.E. besser EMB würde mal dran sitzen um das Problem zu lösen. Ich verwende wo immer es geht interfaced Objekte. Zwar gilt auch "Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher" - jedoch habe ich hier auf Erden noch nie einen gefunden, der das fehlerfrei beherrscht.
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
557 Beiträge
 
Delphi 12 Athens
 
#15

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 20. Dez 2018, 15:50
Da würde mich interessieren, auf welchem programmatischen Wege Emba das Problem lösen könnte.
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.444 Beiträge
 
Delphi 11 Alexandria
 
#16

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 20. Dez 2018, 18:27
So wie es C# macht oder Delphi bei den interfaced Klassen. Da geht es ja auch.
Für eine einfache Klasse nur deswegen ein interface zu machen ist oft recht lästig.
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
557 Beiträge
 
Delphi 12 Athens
 
#17

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 20. Dez 2018, 18:31
Oh, du meinst Garbage Collection einführen? Was macht dann himitsu? Seine Signatur ist doch mittlerweile eingebrannt und nicht mehr änderbar.

Meine Privatmeinung als Amateur: Wäre eine fundamentale Sprachänderung und erscheint undurchführbar.
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.444 Beiträge
 
Delphi 11 Alexandria
 
#18

AW: Warum meckert FastMM hier ein Speicherleck an?

  Alt 21. Dez 2018, 11:20
Nein, ich meine nicht Garbage Collection sondern Referenzzählung.
Allerdings lag ich mit C# falsch, die haben keine Referenzzählung sondern doch Garbage Collection.

Die Signatur ist eingebrannt? Aber dann ist sie doch Müll. Daraus folgt dass himitsu kein Delphianer ist

Geändert von freimatz (21. Dez 2018 um 11:23 Uhr) Grund: Mülltrennung
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz