Hallo zusammen,

Im Rahmen eines Beispielprojekts habe ich das in Spring4D implementierte TSingleton demonstriert.

Ich hatte hierzu auch eine Klasse, wo ich testweise einen "class constructor" (also nicht den normalen Instanz-constructor) implementiert hatte,
da ich hier der Form wegen einen eigenen Demo-Referenzcounter initialisieren wollte.

Im Projekt habe ich FastMM4 aktiviert.

Aufgefallen ist mir, daß Klassen, welche einen (zusätzlichen) "class constructor" haben, einen Memory Leak verursachen.

Die Frage für mich ist momentan, ob das nun in irgendeiner Weise ein Bug ist oder ich hier evtl. das Offensichtliche einfach nur übersehe und ich in einer Klasse, von welcher ich normale Instanzen erzeugen möchte, evtl. gar keinen "class constructor" machen darf, weil ich hierdurch den Typ oder das Verhalten der Klasse ändere. Oder übersehe ich ganz was anderes?

Der reduzierte Beispielcode (Den Teil mit dem FInstanceCount kann man auch komplett rausnehmen, es reicht, daß der "class constructor" vorhanden ist):

markieren

Code:

unit Tests;

interface

type
  TMyClass1 = class(TObject);

  TMyClass2 = class(TObject)
  strict private class var
    FInstanceCount: Integer;
  public
    class constructor Create();
  end;

  TTest = record
  public
    class procedure Test(); static;
  end;


implementation

uses
  Spring.DesignPatterns;

{ TTest }

class procedure TTest.Test();
begin
  // Passt:
  Spring.DesignPatterns.TSingleton.GetInstance<TMyClass1>;
  // Memory-Leak:
  Spring.DesignPatterns.TSingleton.GetInstance<TMyClass2>;
end;

{ TMyClass2 }

class constructor TMyClass2.Create();
begin
  inherited;
  FInstanceCount := 0;
end;

end.

Könnte es am inherited liegen ?

----

Am inherited liegt es nicht.

Der Code lässt sich auf Folgendes reduzieren und hierbei kommt es schon zum Memory Leak.

markieren

Code:

...
  TMyClass2 = class(TObject)
  public
    class constructor Create();
  end;

...

class constructor TMyClass2.Create();
begin
  //
end;

Was sagt denn FastMM4 zum Stack wo der Leak herkommen soll? Ich kann bei mir keinen nachstellen (Delphi 10.0 Seattle + Spring 1.1)

Bei mir mit Delphi 10.1 mit Spring Release 1.2.2.
Auch im Delphi 10.4.1 mit der gleichen Springversion.

Der FastMM4 Stacktrace ist dieser hier:

markieren

Code:

--------------------------------2020/10/5 9:43:39--------------------------------
A memory block has been leaked. The size is: 12

This block was allocated by thread 0x5520, and the stack trace (return addresses) at the time was:
5005A246 [System.pas][System][System.@GetMem][4840]
5005FB37 [System.pas][System][System.TObject.NewInstance][17837]
5006030E [System.pas][System][System.@ClassCreate][19227]
5005FC1C [System.pas][System][System.TObject.Create][17896]
5023DAB4 [System.SyncObjs.pas][System.SyncObjs][System.SyncObjs.TCriticalSection.Create][1092]
4068E4 [Tests][Designpatterns.TSingleton.%GetInstance$p15Tests.TMyClass2%$qqrv$p15Tests.TMyClass2]
406835 [Tests.pas][Tests][TTest.Test][31]
4084F3 
773F6359 [BaseThreadInitThunk]
77537B74 [RtlGetAppContainerNamedObjectPath]
77537B44 [RtlGetAppContainerNamedObjectPath]

The block is currently used for an object of class: TMyClass2

The allocation number is: 1107

Current memory dump of 256 bytes starting at pointer address 7FDC9A18:
F0 67 40 00 00 00 00 00 CC A6 FF 88 2C D9 40 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 54 04 00 00 46 A2 05 50 F1 2F 09 50 18 B5 E5 50 FF 84 40 00 59 63 3F 77
74 7B 53 77 44 7B 53 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 55 00 00 20 55 00 00
62 A2 05 50 DD 2F 09 50 F4 1B 06 50 04 85 40 00 59 63 3F 77 74 7B 53 77 44 7B 53 77 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 77 7C 34 2D 38 D6 40 00 2C D9 40 00
2C D9 40 00 88 83 CB D2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ð  g @  . . . . . Ì  ¦  ÿ  &#710; , Ù  @  . . . . . . . . . . . . . . . . .
. . . . . . . . T . . . F ¢  . P ñ  /  . P . µ  å  P ÿ  &#8222; @  . Y c ?  w
t {  S w D {  S w . . . . . . . . . . . . . . . .    U . .    U . .
b ¢  . P Ý  /  . P ô  . . P . &#8230; @  . Y c ?  w t {  S w D {  S w . . . .
. . . . . . . . . . . . . . . . . . . . w |  4  -  8  Ö  @  . , Ù  @  .
, Ù  @  . &#710; &#402; Ë  Ò  . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

--------------------------------2020/10/5 9:43:39--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

5 - 12 bytes: TMyClass2 x 1

Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".

.. aber wenn der Leak schon im Code (#4) auftritt, dann kann es ja nicht im Spring4D liegen.

Hat die Klasse einen Destructor?

Grüße
Klaus

Gibst du alle deine erstellten Klassen wieder frei?
Zumindest sieht man in deinem Code nichts davon.

Ich denke, der Fehler tritt schon bei Verwendung von Spring auf, aber eben auch wenn der class constructor leer ist. Nimmt man den Spring-Aufruf für die Klasse raus, wird vermutlich auch kein Leak entstehen.

Grundsätzlich ist auch gar nicht sicher, dass es sich wirklich um ein Leak handelt. Und wenn es ein Leak ist, ob ein Leak für ein Singleton überhaupt den Aufwand Wert ist es zu entfernen.

In jedem Fall ware @Stevie aber hier der richtige Ansprechpartner.

Wobei dieser Class-Constructor eh nutzlos ist, da diese Class-Variable sowieso beim Start immer 0 ist.