AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

[Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

Ein Thema von neo4a · begonnen am 1. Feb 2012 · letzter Beitrag vom 1. Feb 2012
Antwort Antwort
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#1

[Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 09:41
Dependency Injection mit dem Spring4Delphi-Framework leistet bei mir seit einiger Zeit gute Dienste. Bislang habe ich das ausschließlich mit nicht-visuellen Klassen praktiziert.

Nun möchte ich das Konzept auf DataModules erweitern:
Delphi-Quellcode:

type
  IdcWallpaper = interface
    ['{E0D26B15-55CE-400A-9DD5-6EA5A999B375}']
    procedure CreateControl(aStartScreen : IdcStartScreen; aParent : TWinControl);
  end;

  TdmWallpaper = class(TDataModule, IdcWallpaper)
  private // IdcWallpaper
    procedure CreateControl(aStartScreen : IdcStartScreen; aParent : TWinControl);
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  end;

implementation

{$R *.dfm}

uses
  Spring.Container,
  Spring.Services;

<..>

initialization
  GlobalContainer.RegisterComponent<TdmWallpaper>.Implements<IdcWallpaper>.AsSingleton.DelegateTo(
    function: TdmWallpaper
    begin
      Result := TdmWallpaper.Create(nil);
    end
  )
Mit diesem Gerüst klappt auch alles sehr schön und ich kann das Datenmodul über den DI-Container benutzen. Es wird der Default-Konstruktor und auch der Default-Destruktor durchlaufen.

Leider bekomme ich trotzdem eine MemoryLeak-Meldung (leaks are: 13-20 bytes dcWallpaper$43200$ActRec x 1)
Hier gibt es eine Erklärung, dass es sich dabei wohl um den Namen der anonymen Funktion handelt, also der Funktion, die ich mittels DelegateTo aufrufe.

Hat jemand dazu eine Idee, wie ich dieses MemoryLeak vermeide?

Edit: Wenn ich das Interface in einem separaten TInterfacedObject implementiere und dort das TDataModule verwalte, gibt es keine Probleme, weil dann auch kein DelegateTo mehr nötig ist.
Andreas

Geändert von neo4a ( 1. Feb 2012 um 09:42 Uhr) Grund: Problem gelöst.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.842 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#2

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 13:15
Die Ursache liegt irgendwo im Compiler - genau das gleiche Problem hatten wir auch in Spring selber vor einiger Zeit.

Wahrscheinliche Lösung (ungetestet):
Delphi-Quellcode:
procedure RegisterWallpaper;
begin
  GlobalContainer.RegisterComponent<TdmWallpaper>.Implements<IdcWallpaper>.AsSingleton.DelegateTo(
    function: TdmWallpaper
    begin
      Result := TdmWallpaper.Create(nil);
    end
  )
end;

initialization
  RegisterWallpaper();

Edit: Hab den QC Eintrag dazu gefunden.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#3

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 14:41
Vielen Dank für Deinen Tipp. Leider bringt Dein Vorschlag keine Besserung, obwohl ich ihn gern übernommen hätte. Meine Lösung mit einem Wrapper-Objekt erzeugt nicht gerade Clean Code, funktioniert dafür aber.

Dein Link enthält im Kommentar die Erklärung: Alle Variablen, die in einem Initialisierungsteil erzeugt werden, sind global. Damit fallen sie auch aus dem Scope, den der DI-Container verwalten kann und erzeugen beim Shutdown MemoryLeaks.

Nun werden ja auf einem Datenmodul einige Komponenten abgelegt. Diese sind dann auch von o.g. Phänomen betroffen, da sie im Create() erzeugt werden.

BTW, ich werde mir meine Erklärung in den Info-Header meiner Units schreiben, damit ich beim nächsten Refactoring nicht flasch optimiere
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.842 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#4

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 14:54
Zitat:
What happens is that a local variable is added to the current routine which contains the address of the method or function pointer, and then this local variable is captured by a hidden anonymous method. This hidden anonymous method is kept alive for the duration of the current routine by a second local variable, of type IInterface (this prevents premature disposal).

The trouble is that with unit initialiaztion, and program begin/end, and similar top-level blocks, "local" variables are in fact global variables.
D.h. das "object behind the scene" (dcWallpaper$43200$ActRec), welches hinter der anonymen Methode sitzt (wir erinnern uns: eine Anonyme Methode ist eigentlich nix anderes als eine Interface Methode mit nen bisschen compiler magic) wird im Falle der Benutzung in initialization (auch in finalization oder in der "main" der dpr) in der globalen Variable gespeichert. Lagerst du aber den Code, welchen du zuvor direkt unter initialization hattest in eine Routine aus, wird die Variable lokal in der Routine angelegt. Somit ist sie nicht mehr global, da sie einen kleineren Scope hat (nämlich den der Routine) und du hast auch kein Memleak mehr.

Das hat imho überhaupt nichts mit der Verwaltung des vom DI Container erzeugten Objekts zu tun.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#5

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 15:47
Das klingt schon überzeugend...noch überzeugender ist nur, dass die vorgeschlagene Änderung mit der Auslagerung in eine Prozedur leider keinen Effekt zeigte.

Diese anonyme Methode ist ja nur nötig, damit der Default-Konstruktor des DatenModuls aufgerufen wird. Möglicherweise passiert dabei noch etwas mehr. Nehme ich nun mein ungeliebtes Wrapper-Object, so verwaltet der DI-Vontainer das Objekt wie gehabt und richtig und innheralb dessen habe ich die volle Kontrolle über das Erzeugen und Freigeben des Datenmodules.

BTW, in den Spring-Demos wird das DelegateTo auch im initialization-Teil eingesetzt. Allerdings werden da auch keine Datenmodule oder Forms erzeugt.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.842 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 15:57
Sicher, dass du ein Memleak der anonymen Methode aus dem Eingangspost hast und nicht eins des Datamodules? Dieses ist nämlich von TComponent abgeleitet, welches kein RefCounting hat und dementsprechend auch nicht über das Interface freigegeben wird (außer, du hast das selber dazwischen geschaltet).
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#7

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 16:27
Eigentlich schon. Dein Einwand mit TComponent ist auch berechtigt, aber:

- sollte nicht der DI-Container die Lebenszyklen verwalten?
- sollte der DI-Container nicht auch Nicht-RefConted-Objekte "können"?
- der Default-Destruktor wurde ja durchlaufen.
- sollte ein leeres TDatamodule eigentlich keine MemLeaks erzeugen?

Wie auch immer: Derzeit und mangels gesicherter Erkenntnisse wrappe ich nicht gerefcountete Objecte mit einem gerefcounteten, schäme mich für mein Denglisch und nutze das Konstrukt weiter mit den Spring-DI-Container und entwickle so immer fein gegen Interfaces, dass N. Hodgess [sic!] seine Freude dran hätte
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.842 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#8

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 18:44
- sollte nicht der DI-Container die Lebenszyklen verwalten?
Woher soll der wissen, ob du in deinem Release auf RefCount = 0 überprüfst und dann Free aufrufst (TInterfacedObject) oder ob du nix machst?
Alles, was du in über Interfaces auf dem Container holst, sollte RefCounting benutzen. Genau das gleiche Problem hatte ich mit meinen Views im PresentationModel ja auch. Dort hab ich allerdings noch ein bisschen "drumrum gepfuscht".

- sollte der DI-Container nicht auch Nicht-RefCounted-Objekte "können"?
Wär schön, und siehe da, wir sind bei dem Dilemma, was Delphi hat. Interfaces sind immer COM Interfaces und nur die Implementierung der Klasse bestimmt, ob sie counted werden oder nicht.

- der Default-Destruktor wurde ja durchlaufen.
Ein Blick in den Code zeigt (wusste ich bisher auch nicht), dass dort für Singletons das Free durch den LifetimeManager explizit aufgerufen wird. Würdest du dort keine Singleton Registrierung benutzen, hättest du ne Handvoll geleakte Objekte.

- sollte ein leeres TDatamodule eigentlich keine MemLeaks erzeugen?
siehe die vorherigen Antworten

Wie auch immer: Derzeit und mangels gesicherter Erkenntnisse wrappe ich nicht gerefcountete Objecte mit einem gerefcounteten, schäme mich für mein Denglisch und nutze das Konstrukt weiter mit den Spring-DI-Container und entwickle so immer fein gegen Interfaces, dass N. Hodgess [sic!] seine Freude dran hätte
Wird das beste sein, wenn du nicht in jedes TComponent Derivat das Refcounting nachrüsten möchtest.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#9

AW: [Spring-DI] MemoryLeak bei Einsatz von DelegatedConstructor

  Alt 1. Feb 2012, 20:38
Wie auch immer: Derzeit und mangels gesicherter Erkenntnisse wrappe ich nicht gerefcountete Objecte mit einem gerefcounteten
Wird das beste sein, wenn du nicht in jedes TComponent Derivat das Refcounting nachrüsten möchtest.
Es gibt so oder so etwas boilerplate code, aber das Ergebnis rechtfertigt es: Dass die Uses-List in den Units meiner Projekte immer kürzer wird, gibt mir irgendwie ein gutes Gefühl
Andreas
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 18:59 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf