AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi Memory Leak nach Zuweisung eines Resourcestream
Thema durchsuchen
Ansicht
Themen-Optionen

Memory Leak nach Zuweisung eines Resourcestream

Ein Thema von Peter-Pascal · begonnen am 4. Jun 2022 · letzter Beitrag vom 14. Jun 2022
Antwort Antwort
Seite 1 von 2  1 2      
Peter-Pascal

Registriert seit: 18. Feb 2007
Ort: 32139 Spenge
199 Beiträge
 
Delphi 11 Alexandria
 
#1

Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 11:32
Hallo,

ich hoffe in dieser Rubrik richtig zu sein.

Meine Frage gilt folgender Zuweisung und anschließendem Memory Leak:
Delphi-Quellcode:
procedure TFormViewFinMathZins.FormCreate(Sender: TObject);
begin
  Image1.Bitmap.LoadFromStream(TResourceStream.Create(HInstance, 'EWoZZ', RT_RCDATA));
end;
Nach Beendigung des Programms bekomme ich beigefügte Meldung über unerwartete (schwarze) Löcher im Speicher. Das leuchtet mir schon ein, aber wie bekomme ich das Loch gestopft?

Wähle ich folgende Variante:
Delphi-Quellcode:
procedure TFormViewFinMathZins.FormCreate(Sender: TObject);
var
  Stream: TStream;
begin
  Stream:= TResourceStream.Create(HInstance, 'EWoZZ', RT_RCDATA);
  Image1.Bitmap.LoadFromStream(stream);
  FreeAndNil(stream)
end;
habe ich logischerweise das Problem nicht.
Meine Frage: Ist es möglich bei der ersteren (eleganteren) Variante die Ressource zu beenden?

Vielen Dank für eure Mühe und
viele Grüße Peter
Miniaturansicht angehängter Grafiken
memoryleak.png  
Peter Niemeier
  Mit Zitat antworten Zitat
peterbelow

Registriert seit: 12. Jan 2019
Ort: Hessen
704 Beiträge
 
Delphi 12 Athens
 
#2

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 11:41
Die zweite Variante ist die richtige, allerdings solltest Du das mit einem try finally Block machen.

Delphi-Quellcode:
procedure TFormViewFinMathZins.FormCreate(Sender: TObject);
var
  Stream: TStream;
begin
  Stream:= TResourceStream.Create(HInstance, 'EWoZZ', RT_RCDATA);
  try
    Image1.Bitmap.LoadFromStream(stream);
  finally
    stream.free;
  end;
end;
Du kannst Dir allerdings den stream sparen, TBitmap hat auch eine LoadFromResourceName-Methode...
Peter Below

Geändert von peterbelow ( 4. Jun 2022 um 11:44 Uhr)
  Mit Zitat antworten Zitat
mytbo

Registriert seit: 8. Jan 2007
472 Beiträge
 
#3

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 12:31
Meine Frage: Ist es möglich bei der ersteren (eleganteren) Variante die Ressource zu beenden?
Image.Bitmap.LoadFromResourceName(HInstance, 'EWoZZ');

Nachtrag: Peter hat schon den richtigen Hinweis gegeben.

Bis bald...
Thomas

Geändert von mytbo ( 4. Jun 2022 um 12:36 Uhr) Grund: Peter war schneller
  Mit Zitat antworten Zitat
Peter-Pascal

Registriert seit: 18. Feb 2007
Ort: 32139 Spenge
199 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 12:46
Vielen Dank an Peter und Thomas,

es sind gleich einige nützliche Tipps. Danke dafür.

Ich tue mich bei den Try .. finaly Blöcke etwas schwer und bin eher versucht alles mit Try-Blöcken zu schützen, als zu wenig. Dann frage ich mich, ist es nicht auch Ressourcen-Verschwendung?

Try-Blöcke sehe ich voll und ganz ein, bei Fällen wie oben. Also laden von
-Bildern
-Formulare
-Ressourcen allgemein: Dateien

Haben Try-Blöcke Grenzen?

Darf ich noch eine Frage stellen?

Ich muss in mein kleines FinMath-Programm viele Formeln als PNG laden. Ist dies über "Ressourcen und Bilder" der richtige Weg oder gibt es einen besseren, hinsichtlich Ressourcen schonen? Ich weiß nie so richtig, wonach ich entscheiden soll. Gerade wenn ein Programm viele Graphiken (PNG) anzeigen soll bläht das Programm sehr stark auf. Wie geht man vor?

Vielen Dank noch mal
Peter Niemeier
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
2.960 Beiträge
 
Delphi 12 Athens
 
#5

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:02
Hallo,

du kannst die PNGs ja auch als Dateien mitliefern und diese laden.
z. B. in ein TImage oder TBitmap etc.

Dann sind die mal nicht in der exe-Datei drin.

Grüße
TurboMagic
  Mit Zitat antworten Zitat
mytbo

Registriert seit: 8. Jan 2007
472 Beiträge
 
#6

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:10
Wie geht man vor?
Was ist für dich viel? Du könntest deine Ressourcen in eine "Resourcen-DLL" auslagern, oder eine ZIP Datei verwenden. Wenn die Datenquelle schon komprimiert ist, kannst du sie auch ohne zweite Komprimierung in einer ZIP Datei ablegen. Wird noch mehr Funktionalität benötigst, wäre eine SQLite Datenbank als Datengrab eine Überlegung wert.

Bis bald...
Thomas
  Mit Zitat antworten Zitat
Peter-Pascal

Registriert seit: 18. Feb 2007
Ort: 32139 Spenge
199 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:12
ja, von Datei ist eine Möglichkeit und wenn man nicht möchte, dass der User die Dateien selber nutzt, wäre vielleicht eine verschlüsselte Zip-Datei eine Möglichkeit. ZIP klingt gut.
Wird das Programm so nicht langsam?

Ich frage mich gerade, wie machen das eigentlich Spieleprogrammierer? Viele Texturen sind schließlich nachwievor Bilder.

Du hast recht Thomas, es kommt tatsächlich auf die Menge an. Möglicherweise nutzen Spieleprogrammierer wohl eine SQLite Datenbank.

Wie mache ich eine Reccourcen-DLL?

Wie so oft, es kommt wohl auf den Einzelfall an.

Danke TurboMagic und Thomas
Peter Niemeier

Geändert von Peter-Pascal ( 4. Jun 2022 um 13:16 Uhr)
  Mit Zitat antworten Zitat
mytbo

Registriert seit: 8. Jan 2007
472 Beiträge
 
#8

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:24
Wird das Programm so nicht langsam?
Was ist für dich schnell? Du kannst dir hier zur Orientierung ein paar Werte anschauen. Mit einem weniger sicheren Algorithmus ist es noch viel schneller.

Infos zum Thema "Resource-DLL" findest du hier im Forum.

Bis bald...
Thomas
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#9

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:35
wie:

eine leere DLL erstellen
und da deine Ressourcen rein

Manuell über eigene RES, bzw. RC, via {$R ...} , bzw. {$RESOURCE ...} ,
und/oder über die Projekt-Resource (Mainmenü > Projekt > Ressourcen und Bilder)


und dann beim Laden statt HInstance (dem Handle der EXE), das Handle der DLL verwenden.
LoadLibrary oder MSDN-Library durchsuchenLoadLibraryEx + LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE oder LOAD_LIBRARY_AS_DATAFILE
oder GetModuleHandle, wenn die DLL statisch eingebunden wurde, bzw. bereits geladen ist.
$2B or not $2B

Geändert von himitsu ( 4. Jun 2022 um 13:40 Uhr)
  Mit Zitat antworten Zitat
Peter-Pascal

Registriert seit: 18. Feb 2007
Ort: 32139 Spenge
199 Beiträge
 
Delphi 11 Alexandria
 
#10

AW: Memory Leak nach Zuweisung eines Resourcestream

  Alt 4. Jun 2022, 13:53
Danke Himitsu,
klingt gut, aber auch kompliziert.
Ich habe mir Deine Antwort kopiert, um es auszuprobieren.
Könnte eine weitere gute Möglichkeit sein, Bilder in einem Programm zu verwenden. Neben ZIP und SQLite.
Mit dem Link von Thomas bekomme ich eine Orientierung.

Am liebsten wäre mir ja SVG, aber das hat halt Grenzen. Ich denke in vielen Fällen führt kein Weg an Pixel-Bilder vorbei.
Peter Niemeier
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


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 08:28 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