Speicherleck bei der Verwendung von anonymen Methoden

[FredlFesl]

Zitat von carlo93:

Ich hatte nicht gefragt...

So ziemlich jeder Beitrag liefert Antworten und Informationen jenseits deiner Fragen.

Folgerichtig wäre der einzig wahre Beitrag, bei dem Du nichts zu bemängeln hättest, dieser hier:
"Ja. Ja."

Zitat von carlo93:

Ohne einen überheblichen Ton kannst du wohl überhaupt nichts von dir geben?

Ich glaub, ich brauch Nachhilfe. Ich find den 'überheblichen Ton' nämlich nicht.

[carlo93]

Danke himitsu und Thom! Das hilft mir weiter.

@Stevie
Danke für's Nachschauen. Dennoch macht für mich gerade der Ton die Musik. Ein "Ist schon lange bekannt" beinhaltet im Unterton ein "Ach - und dir nicht!? Wohl keine Ahnung von der Thematik?".
Auf eine sachlich gestellte Frage erwarte ich auch eine sachliche Antwort. Die meisten hier im Forum können das. Im Gegensatz dazu klingt nahezu jede Antwort von Dir überheblich. Schade - bei Deinem Wissen hättest Du das eigentlich nicht nötig.

Zum Thema "Workarounds"

1. Report #: 83259 None
2. Report #: 78066 Put anonymous method in function. (Entspricht Sebastian's Vorschlag vor Deinem Beitrag)

Beide Einträge betreffen übrigens "Version: 14.0". Dumme Frage: Gab's zu diesem Zeitpunkt schon anonyme Methoden?

Zitat von FredlFesl:

Folgerichtig wäre der einzig wahre Beitrag, bei dem Du nichts zu bemängeln hättest, dieser hier:
"Ja. Ja."

@FredlFesl
Sorry - aber das ist einfach dumm und keine sachliche Antwort wert.

Zitat von FredlFesl:

Ich glaub, ich brauch Nachhilfe. Ich find den 'überheblichen Ton' nämlich nicht.

Das ist durchaus möglich. Ich weiß nicht, wie alt Du bist - ich gehöre einer Generation an, die (noch) gelernt hat, seinem Gegenüber eine entsprechende Portion an Respekt und Achtung entgegenzubrigen. Und zwar unabhängig vom Alter, Geschlecht und Wissensstand. So etwas scheint aber leider immer mehr aus der Mode zu kommen. Wer einen derartigen Ton für angemessen hält, kann diesen gern unter denen anwenden, die das für normal halten - bei mir bitte nicht.

Stevie's Post brachten - außer mehreren Belehrungen - keinen Beitrag zur Lösung des Problems. Wozu also das Ganze?
Das es ganz anders geht, beweisen die Beiträge von Sebastian, himitsu und Thom. Nochmals vielen Dank an die drei!

Damit beende ich die Off-Topic-Diskussion meinerseits. Wer noch Bemerkungen dazu hat - bitte per PM.

[Stevie]

Edit: egal...

[FredlFesl]

Zitat von carlo93:

Sorry - aber das ist einfach dumm und keine sachliche Antwort wert.

Es entspricht dem, was Du erwartest. Antworten auf deine Fragen und sonst nix.

Zitat:

Das ist durchaus möglich.

Aha. Das dachte ich mir. Zwischen den Zeilen kann man übrigens alles lesen. Das lehrt mich meine Lebenserfahrung. Und lass uns nicht über Alter und Generation reden. Das könnte nach hinten losgehen

Zitat:

Stevie's Post brachten - außer mehreren Belehrungen - keinen Beitrag zur Lösung des Problems.

Doch. Aber man muss klicken und selbst im QC nachlesen. Das könnte natürlich überheblich sein

Überheblich könnte übrigens auch der sein, der frisch in einem Forum ist und gleich rumkoffert.

[BUG]

Ja, manche Mitglieder sind manchmal etwas unhöflich oder streitlustig.
Wenn du Stevies ersten Betrag anstößig findest solltest du dir aber ein dickeres Fell zulegen. Durch solche Reaktionen wie von dir eskalieren solche Situationen häufig und damit geht dir eine Menge Antworten, vernünftiger Diskussion und letztlich Wissen verloren.
Und: die Links zu den QC-Einträgen sind wertvolle Informationen und wenn nicht dir, dann helfen sie vielleicht später jemand anderem der diesen Thread liest.

[Mithrandir]

Sehe ich genau so. Und nu' kommt mal wieder auf den Boden der Tatsachen zurück. Vor dem nächsten Posting einfach dreimal durchatmen und sich fragen, ob das die Sache wirklich wert ist.

[WladiD]

Zurück zum Thema. Soweit ich mich entsinnen kann, reicht es aus, wenn die Referenz der anonymen Methode explizit auf nil gesetzt wird.

Also in deinem Fall irgendwo im Destruktor:

FProc := nil;

Und der Leak dürfte verschwinden.

[Stevie]

Zitat von WladiD:

Zurück zum Thema. Soweit ich mich entsinnen kann, reicht es aus, wenn die Referenz der anonymen Methode explizit auf nil gesetzt wird.

Also in deinem Fall irgendwo im Destruktor:

FProc := nil;

Und der Leak dürfte verschwinden.

Leider nicht, wie Thom oben schon richtig anmerkte, läuft da irgendwas bei der Code Generierung schief, was dazu führt, dass der RefCount des hinter der anonymen Methode liegenden Objects falsch gezählt wird. Das auf nil setzen geschieht auf jeden Fall implizit. Das ganze (einmal zu oft _AddRef oder einmal zu wenig _Release, wie man will) passiert beim Zusammenspiel von lokaler Variable und verschachtelter anonymer Methode (da wird zu Beginn ein _IntfCopy gemacht, was zu dem erhöhten RefCount führt)

Zusätzlich zu den in den QC Einträgen wäre der simpelste Testcase, der mir gerade einfällt, folgender:

Delphi-Quellcode:

program Test;

{$APPTYPE CONSOLE}

uses
  SysUtils;

type
  TTest = class
  private
    FProc: TProc;
  public
    constructor Create;
  end;

constructor TTest.Create;
var
  Proc: TProc;
begin
  Proc := procedure begin end;
  FProc := procedure begin end;
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  TTest.Create.Free;
end.

[Thom]

Noch eine Merkwürdigkeit im Zusammenhang mit anonymen Methoden:

Eine anonyme Methode ist nach außen hin nur ein einfacher Pointer. Ein SizeOf(TProc) liefert also unter 32 Bit erwartungsgemäß 4 Byte. Im Gegensatz dazu bestehen Objekt-Methoden aus einem Daten- und einem Code-Pointer. Deshalb liefert SizeOf(TMethod)=8 (unter 32 Bit).

Jetzt sollte man natürlich annehmen, daß der doppelt so große Wert von TMethod nicht zuweisungskompatibel zum "kleineren" TProc ist.
Entgegen jeder Logik funktioniert das aber doch: Der Compiler generiert bei einer derartigen Zuweisung einfach eine anonyme Methode und bindet die Variable Self, die zu der Objekt-Methode gehört.
Ich finde dieses Verhalten genial, da damit Ereignishandler wahlweise Objekt- oder anonyme Methoden sein können.

Ein kleines Beispiel:

Delphi-Quellcode:

type
  TNotifyProc = TProc<TObject>; //anstelle von TNotifyEvent

  TMyObject = class
  private
    FValue: Integer;
    FOnChange: TNotifyProc;
    procedure SetValue(Value: Integer);
  public
    property Value: Integer read FValue write SetValue;
    property OnChange: TNotifyProc read FOnChange write FOnChange;
  end;

  TForm1 = class(TForm)
  [...]
  private
    procedure MyObjectChange(Sender: TObject);
  end;

procedure TMyObject.SetValue(Value: Integer);
begin
  if FValue<>Value then
  begin
    FValue:=Value;
    if assigned(FOnChange)
      then FOnChange(Self);
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  MyObject: TMyObject;
begin
  MyObject:=TMyObject.Create;
  try
    MyObject.OnChange:=MyObjectChange;
    MyObject.Value:=1;
    MyObject.OnChange:=procedure(Sender: TObject)
                       begin
                         ShowMessage(IntToStr(TMyObject(Sender).Value));
                       end;
    MyObject.Value:=2;
  finally
    MyObject.Free;
  end;
end;

procedure TForm1.MyObjectChange(Sender: TObject);
begin
  ShowMessage(IntToStr(TMyObject(Sender).Value));
end;

[himitsu]

Referenzen bestehen intern aus einem geheimgehalten Interface.
Und ein Interfacezeiger ist nunmal auch nur ein Pointer.

Schade eigentlich, denn durch die Geheimhaltung und mangels entsprechender öffentlicher Methoden kann man Referenzen dadurch nicht vergleichen, bzw. prüfen was sich darin befindet.


Wobei die Referenzen keine Methoden als anonyme Methoden "binden", sondern sie können einfachen alles "aufnehmen" ... vermutlich besitzen sie intern Speicher (eventuell überladen) und eine Typ-Variable, welche die Art des aufgenomenen "Zeigers" angibt. Bei einem Aufruf wird dann einfach der entsprechende Typ ausgewertet und aufgerufen.


property OnChange: TNotifyProc read FOnChange write FOnChange; .
Hierfür wollte ich mir mal eine TList<> erstellen, welche mehrere Events verwalten kann, aber leider war es mir nicht mehr möglich einmal registrierte Events "geziehlt" wieder aus der Liste zu entfernen.

PS: Im Zusammenhang mit anonymen Methoden, nimmt diese Referenz auch noch ganze Sätze von geshareten Variablenzeigern mit in sich auf.

Delphi-Quellcode:

    MyObject.OnChange:=procedure(MySender: TObject)
                       begin
                         ShowMessage(MySender.ClassName + ' ' + IntToStr(TMyObject(MySender).Value) + ' ' + Sender.ClassName);
                       end;