Unerklärlicher Speicherfresser

[TurboMagic]

Eine weitere Erkenntnis:

Der Aufruf von New springt nach GETMEM.INC und zwar in diese Routine:

Delphi-Quellcode:

function SysGetMem(Size: NativeInt): Pointer;
asm
{$ifdef CPU386}
{---------------32-bit BASM SysGetMem---------------}
  {On entry:
    eax = ASize}
  {Since most allocations are for small blocks, determine the small block type
   index so long}
  lea edx, [eax + BlockHeaderSize - 1]
  shr edx, 3
  {Is it a small block?}
  cmp eax, (MaximumSmallBlockSize - BlockHeaderSize)

Im Falle des funktionierenden Testprogramms wird nach der lea edx... Zeile shr edx, 3 ausgeführt.
Im Falle des nicht funktionierenden Programms, springt lea zurück nach
function _GetMem(Size: NativeInt): Pointer; von wo aus mal MemoryManager.GetMem aufgerufen
worden war.

Also Frage: was veranlasst lea zurück zu springen, anstatt weiter zu laufen.
Im funktionierenden Testprogramm ist [eax + BlockHeaderSize - 1] = 13 und im anderen
ist eax = 10 und BlockheaderSize = 4, was ja genau das selbe ist. Wir können nur edx da nicht mehr
prüfen, da dann schon der Sprung erfolgt ist.

Grüße
TurboMagic

[peterbelow]

Zitat von TurboMagic:

Eine weitere Erkenntnis:

Der Aufruf von New springt nach GETMEM.INC und zwar in diese Routine:

Delphi-Quellcode:

function SysGetMem(Size: NativeInt): Pointer;
asm
{$ifdef CPU386}
{---------------32-bit BASM SysGetMem---------------}
  {On entry:
    eax = ASize}
  {Since most allocations are for small blocks, determine the small block type
   index so long}
  lea edx, [eax + BlockHeaderSize - 1]
  shr edx, 3
  {Is it a small block?}
  cmp eax, (MaximumSmallBlockSize - BlockHeaderSize)

Im Falle des funktionierenden Testprogramms wird nach der lea edx... Zeile shr edx, 3 ausgeführt.
Im Falle des nicht funktionierenden Programms, springt lea zurück nach
function _GetMem(Size: NativeInt): Pointer; von wo aus mal MemoryManager.GetMem aufgerufen
worden war.

Also Frage: was veranlasst lea zurück zu springen, anstatt weiter zu laufen.
Im funktionierenden Testprogramm ist [eax + BlockHeaderSize - 1] = 13 und im anderen
ist eax = 10 und BlockheaderSize = 4, was ja genau das selbe ist. Wir können nur edx da nicht mehr
prüfen, da dann schon der Sprung erfolgt ist.

Grüße
TurboMagic

Da ist was oberfaul. LEA ist keine Sprunganweisung, sie lädt einfach eine Addresse in ein Register. Wenn danach die nächste Anweisung nicht ausgeführt wird steht da im binären Kode nicht die Anweisung, die laut Source da stehen sollte, sondern was anderes, z. B. ein ret. PLaziere einen Breakpoint möglichst nahe an der lea Anweisung (weis nicht ob das direkt in einem include file geht) und sie dir den Disassembly view an.

[TurboMagic]

@Peter: Das untersuchen wir morgen.
Kollege hat auch schon Compilereinstellungen verlgichen, hat aber auch nichts gebracht.

Konntest du aus unseren Speichermanager Statuswerten noch etwas heraus lesen?

Bis vor kurzem waren diese PMyRegister records in einem Array of PMyRegister, da wir jetzt aber
diverse Lücken in den Registern bekommen, wollten wir das auf das Dictionary umstellen.

Als es noch das Array war, gab's keine Speicherprobleme.

[peterbelow]

Zitat von TurboMagic:

@Peter: Das untersuchen wir morgen.
Kollege hat auch schon Compilereinstellungen verlgichen, hat aber auch nichts gebracht.

Konntest du aus unseren Speichermanager Statuswerten noch etwas heraus lesen?

Das Log sah eigentich völlig normal aus, keine ungewöhnlichen Allokationen und der erste Eintrag der medium block list passt auch zu deinem Record.

So langsam habe ich den Verdacht, dass ihr irgendwo einen memory overwrite error versteckt habt, der irgendwas in den internen Strukturen des MMs verändert. Viel Spaß beim Suchen , sowas kann einen Tage kosten.

Ich würde einen gründlichen Kode review vorschlagen, mit Konzentration auf die Teile, die ihr seit der letzten funktionierenden Version geändert habt, mit Schwerpunkt auf alle Stellen, an denen deine Records oder pointer darauf verwendet werden. Achtet besonders auf Aufrufe von Routinen mit untyped var Parametern, wie TStream.Read. Da reicht ein fehlendes Caret um eine Katastrophe auszulösen .

[Stevie]

Zitat von peterbelow:

Das Log sah eigentich völlig normal aus, keine ungewöhnlichen Allokationen und der erste Eintrag der medium block list passt auch zu deinem Record.

Keineswegs, man sieht, dass die ganzen 10 Byte allokationen nirgendwo zu finden, sind - der erste Block müsste mindestens 896 Allokationen aufweisen.

Zitat von TurboMagic:

Single steppen auf meinem PC (die anderen Tests waren gestern auf dem PC eines Kollegen) im Vergleich zu seinem PC ergibt, dass bei mir das DIsassembly an der LEA Stelle von GetMem einen JMP zeigt, bei ihm jedoch LEA.

Ein Jump direkt als erste Anweisung, sieht nach einem Codepatch/Hook aus - Code mal durchsuchen danach (z.b. nach $E8 oder anderen Repräsentationen des jmp opcodes gefolgt von 4 Byte für die Zieladdresse) - suchen nach WriteProcessMemory kann auch was zutage fördern. Ob man einen Databreakpoint auf ausführbaren Speicher setzen kann, weiß ich nicht, aber wäre auch eine Möglichkeit den Verursacher zu finden.

[bcvs]

Zitat:

{$ifdef CPU386}

Das zeigt ja schon, aus welcher Zeit das stammt. Ich würde auch auf Klassen und generische Listen wechseln, wenn ihr sowieso schon am umstellen seid.

[TurboMagic]

Zitat von bcvs:

Zitat:

{$ifdef CPU386}

Das zeigt ja schon, aus welcher Zeit das stammt. Ich würde auch auf Klassen und generische Listen wechseln, wenn ihr sowieso schon am umstellen seid.

Ähm, das ist die GetMem Routine der RTL!
Die benutzt du übrigens implizit auch andauernd

Und nein, ich glaube nicht dass ein Wechsel auf Objekte hier sinnvoll wäre.
Es würden nämlich im Worst case mehrere Tausend Objektinstanzen angelegt die
nur Daten halten und keinen eigenen Code haben. Das wäre nicht sinnvoll, und
vor dem Beginn der Umstellung auf TDictionary<T> zur Verwaltung der ganzen Daten
war es auch kein Speicherfresser.

=> irgend etwas ging dabei kaputt, es ist aber nicht die Verwendung von
TDictionary<T> an sich schuld daran, sondern jedes New() frisst diesen Speicher
und zu dem Zeitpunkt ist das Dictionary noch nicht ivolviert.

Es wäre immer noch zu klären, warum New im einen programm für jede PMyRegister
Allokation tatsächlich nur 12 Byte oder so allokiert und im anderen für die Allokation
des selben Datentyps plötzlich > 1K! Das ist die bisher unerklärliche Fragestellung.

Diese hat damit zu tun, dass einmal bei LEA Aufruf in GetMem intern normal weiter
gearbeitet wird und einmal wohin gesprungen wird, obwohl LEA kein Sprungbefehl ist.

Ok, im Programm gibt es auch Multithreading, ich werde morgen klären ob dieser Aufruf zur
Erzeugung im GUI Thread oder einem sekundären stattfindet.

[Codehunter]

Wie gesagt, aus dem kleinen Codeschnipsel kann man schlecht auf den konkreten Anwendungsfall schließen. Aber bei den hier genannten Zahlen von "Speicherfresser" zu reden ist irgendwie auch übertrieben

[hoika]

Hallo,
das waren meines Wissens 800 MB ...
also doch schon etwas gefräßig.

[Codehunter]

Zitat von hoika:

Hallo,
das waren meines Wissens 800 MB ...
also doch schon etwas gefräßig.

Hab ich so nicht wahrgenommen. Dann ist es wirklich etwas viel. Meine Favoriten sind immer noch Projekteinstellungen, inline Methoden und in den beiden Projekten unterschiedlich verwendete Units oder Includes. An die eigenmächtige Manipulation des Speichermanagers durch Drittanbieter-Kompos mag ich nicht so recht glauben.