Unerklärlicher Speicherfresser

[TurboMagic]

Hallo,

ich schreibe gerade mittels Tokyo ein Programm, welches Zeiger auf einen Recordtyp anlegt.

Beispiel:

Delphi-Quellcode:

type
  TAuthorizationLevel = (alNone, alEverybody, al1, al2, al3);

  TMyRegister = record
                  Data         : Word;
                  WorkingCopy  : Word;
                  Authorization: TAuthorizationLevel;
                  Data1        : Word;
                  Data2        : Word;
                end;
  PMyRegister = ^TMyRegister;

var
  Reg : PMyRegister;
  i : Integer;

begin
  for i := 0 to 895 do
    New(Reg);
end.

Der Code produziert so natürlich ein Speicherleck, er illustriert aber das Problem
sehr gut. Im eigentlich zu schreibenden Programm ausgeführt, führt er dazu, dass
der Taskmanager (ja, der ist da etwas ungenau, die Differenz ist aber frappierend!)
einen Speicherverbrauch von ca. 4K pro PMyRegister anzeigt, insgesamt also 3620K.

Extrahiere ich den betreffenden Code in ein einfaches Demo Programm (die Schleife im
zu schreibenden Programm macht aber NICHTS anders!!!) und führe es aus, brauchen die
895 PMyRegister zusammen nur 20K, ein einzelnes PMyRegister also ca. 22 Byte.

Beide Programme sind mit $A8 Speicher ausgerichtet.

Woran kann es liegen, dass so ein Record Eintrag einmal ca. 22 Byte benötigt und im
anderen Programm, trotz gleicher Definition, ca. 4K.

Grüße
TurboMagic

[hoika]

Hallo,
ich würde mal FastMM4 nehmen, um den tatsächlichen Speicherverbrauch
und hier das absichtliche memleak zu prüfen.

[TurboMagic]

Hallo,

Tokyo benutzt ja standardmäßig schon FastMM4, allerdings halt "Lite".
Angenommen ich nehme die volle Version, wie bekomme ich damit den Speicherverbrauch analysiert?
Wie ich damit Speicherlecks ermittle weiß ich schon.
Soll ich das also so leaken lassen, damit FastMM4 mir die Größen der geleakten Dinge mitteilt?

Grüße
TurboMagic

[peterbelow]

Zitat von TurboMagic:

Hallo,

ich schreibe gerade mittels Tokyo ein Programm, welches Zeiger auf einen Recordtyp anlegt.

Beispiel:

Delphi-Quellcode:

type
  TAuthorizationLevel = (alNone, alEverybody, al1, al2, al3);

  TMyRegister = record
                  Data         : Word;
                  WorkingCopy  : Word;
                  Authorization: TAuthorizationLevel;
                  Data1        : Word;
                  Data2        : Word;
                end;
  PMyRegister = ^TMyRegister;

var
  Reg : PMyRegister;
  i : Integer;

begin
  for i := 0 to 895 do
    New(Reg);
end.

Der Code produziert so natürlich ein Speicherleck, er illustriert aber das Problem
sehr gut. Im eigentlich zu schreibenden Programm ausgeführt, führt er dazu, dass
der Taskmanager (ja, der ist da etwas ungenau, die Differenz ist aber frappierend!)
einen Speicherverbrauch von ca. 4K pro PMyRegister anzeigt, insgesamt also 3620K.

Extrahiere ich den betreffenden Code in ein einfaches Demo Programm (die Schleife im
zu schreibenden Programm macht aber NICHTS anders!!!) und führe es aus, brauchen die
895 PMyRegister zusammen nur 20K, ein einzelnes PMyRegister also ca. 22 Byte.

Beide Programme sind mit $A8 Speicher ausgerichtet.

Woran kann es liegen, dass so ein Record Eintrag einmal ca. 22 Byte benötigt und im
anderen Programm, trotz gleicher Definition, ca. 4K.

Grüße
TurboMagic

Das sieht so aus, als wenn der Memory manager für jedes New einen 4K Speicherblock vom OS anfordert anstelle den vorherigen zu partitionieren. Sieh Dir mal das Ergebnis von GetMemoryManagerState vor und nach der Testschleife an. Falls Du nicht den default memory manager verwendest check mal alles, was zur Konfiguration des MMs gehört. Soweit ich mich erinnere gibt es da eine Möglichkeit, dem MM zu sagen, was er als "large block" ansehen soll. Wenn das aus irgendwelchen Gründen auf 0 stehen sollte würde es die Symptome erklären...

[TurboMagic]

Danke Peter, schaue wir uns gleich an.

Wir haben inzwischen versucht mittels der vollen FastMM4 rauszufinden wie groß so ein TMyRegister ist.
Wir haben das über das MemoryLeakReporting probiert. Das klappt aus unerfindlichen Gründen aber nur
im Testprogramm und dort ist ein TMyRegister 12 Bytes groß.

Im eigentlichen Programm kann ich versuchen zu leaken was ich will, er bringt einfach keine Meldung
über ein MemoryLeak. Ja ReportMemoryLeaksOnShutdown ist definitiv an und es ist egal ob wir das in Tokyo
eingebaute limitierte reporting nutzen oder FastMM4 aus dem Internet. Er zeigt das nicht an

Grüße
TurboMagic

[hoika]

Hallo,

Zitat:

Soll ich das also so leaken lassen, damit FastMM4 mir die Größen der geleakten Dinge mitteilt?

Korrekt.
Nach dem Beenden deines Programmes erhälst Du eine Datei, die die Klassen (Objekte) anzeigt,
die nicht freigegeben worden sind.

Ausserdem die Größe des jeweiligen Objektes, wenn also "falsch" ausgerichtet wird, auch die Gesamtgröße (glaube ich ...)

Mit deiner "kleinen", eingebauten Version schreibst du als erste Zeile in die DPR

ReportMemoryLeaksOnShutdown := True;

[hoika]

Hallo,
das heisst, in einem Testprogramm klappt es, in deinem richtigen Programm nicht?

Das ist was faul ...

Vergleiche mal die Compiler-Optionen der beiden Programme.
Suche im kompletten Quellcode nach ReportMemoryLeaksOnShutdown, nicht das das irgendwo ausgeknippst wird.
FastMM4 ist wirklich in der DPR?
Nimm dein grosse Projekt, mache ein Exit noch vor dem Erzeugen des Hauptforms und davor das Speicherleck rein,
also ein Objekt oder per GetMem das erzeugen und nicht freigeben.
Damit kannst du prüfen, ob es irgendwas mit den Projektoptionen zu tun hat.

Hie noch mal der Link für die Settings von FastMM4.
https://sergworks.wordpress.com/2018...e-setup-guide/

[Codehunter]

Nur mal ins Blaue hinein: Ist das eine evtl. ein Debug- und das andere ein Release-Build?

[TurboMagic]

Zitat von hoika:

Hallo,
das heisst, in einem Testprogramm klappt es, in deinem richtigen Programm nicht?

Vergleiche mal die Compiler-Optionen der beiden Programme.
Suche im kompletten Quellcode nach ReportMemoryLeaksOnShutdown, nicht das das irgendwo ausgeknippst wird.
FastMM4 ist wirklich in der DPR?
Nimm dein grosse Projekt, mache ein Exit noch vor dem Erzeugen des Hauptforms und davor das Speicherleck rein,
also ein Objekt oder per GetMem das erzeugen und nicht freigeben.
Damit kannst du prüfen, ob es irgendwas mit den Projektoptionen zu tun hat.

Das haben wir schon alles probiert, leider erfolglos.

[TurboMagic]

Zitat von Codehunter:

Nur mal ins Blaue hinein: Ist das eine evtl. ein Debug- und das andere ein Release-Build?

Nein, beides Debug Builds.