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:

Zitat von TurboMagic (Beitrag 1435365)

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:

Zitat von hoika (Beitrag 1435374)

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:

Zitat von Codehunter (Beitrag 1435376)

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

Nein, beides Debug Builds.

[TurboMagic]

Zitat:

Zitat von peterbelow (Beitrag 1435371)

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...

Hier was wir direkt nach der Schleife in eine Log-Datei schreiben konnten:

Small BlockTypeStates:
Internal BlockSize: 16; Useable BlockSize:12; A llocated BlockCount:3; Reserved AddressSpace:29488
Internal BlockSize: 24; Useable BlockSize:20; Allocated BlockCount:21; Reserved AddressSpace:29488
Internal BlockSize: 32; Useable BlockSize:28; Allocated BlockCount:13; Reserved AddressSpace:29488
Internal BlockSize: 40; Useable BlockSize:36; Allocated BlockCount:11; Reserved AddressSpace:29488
Internal BlockSize: 48; Useable BlockSize:44; Allocated BlockCount:4; Reserved AddressSpace:29488
Internal BlockSize: 56; Useable BlockSize:52; Allocated BlockCount:6; Reserved AddressSpace:29488
Internal BlockSize: 64; Useable BlockSize:60; Allocated BlockCount:5; Reserved AddressSpace:29488
Internal BlockSize: 72; Useable BlockSize:68; Allocated BlockCount:8; Reserved AddressSpace:29488
Internal BlockSize: 80; Useable BlockSize:76; Allocated BlockCount:5; Reserved AddressSpace:29488
Internal BlockSize: 88; Useable BlockSize:84; Allocated BlockCount:2; Reserved AddressSpace:58976
Internal BlockSize: 96; Useable BlockSize:92; Allocated BlockCount:2; Reserved AddressSpace:29488
Internal BlockSize: 104; Useable BlockSize:100; Allocated BlockCount:3; Reserved AddressSpace:29488
Internal BlockSize: 112; Useable BlockSize:108; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 120; Useable BlockSize:116; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 128; Useable BlockSize:124; Allocated BlockCount:2; Reserved AddressSpace:29488
Internal BlockSize: 136; Useable BlockSize:132; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 144; Useable BlockSize:140; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 152; Useable BlockSize:148; Allocated BlockCount:1; Reserved AddressSpace:29488
Internal BlockSize: 160; Useable BlockSize:156; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 176; Useable BlockSize:172; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 192; Useable BlockSize:188; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 208; Useable BlockSize:204; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 224; Useable BlockSize:220; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 240; Useable BlockSize:236; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 256; Useable BlockSize:252; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 272; Useable BlockSize:268; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 288; Useable BlockSize:284; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 304; Useable BlockSize:300; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 320; Useable BlockSize:316; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 352; Useable BlockSize:348; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 384; Useable BlockSize:380; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 416; Useable BlockSize:412; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 448; Useable BlockSize:444; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 480; Useable BlockSize:476; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 528; Useable BlockSize:524; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 576; Useable BlockSize:572; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 624; Useable BlockSize:620; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 672; Useable BlockSize:668; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 736; Useable BlockSize:732; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 800; Useable BlockSize:796; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 880; Useable BlockSize:876; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 960; Useable BlockSize:956; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1056; Useable BlockSize:1052; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1152; Useable BlockSize:1148; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1264; Useable BlockSize:1260; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1376; Useable BlockSize:1372; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1504; Useable BlockSize:1500; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1648; Useable BlockSize:1644; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1808; Useable BlockSize:1804; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 1984; Useable BlockSize:1980; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2176; Useable BlockSize:2172; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2384; Useable BlockSize:2380; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0
Internal BlockSize: 2608; Useable BlockSize:2604; Allocated BlockCount:0; Reserved AddressSpace:0

Allocated Medium Block Count: 0
Total Allocated Medium BlockSize: 0
Reserved Medium BlockAddress Space: 868384
Allocated Large Block Count: 0
Total Allocated Large BlockSize: 0
Reserved Large BlockAddress Space0

Grüße
TurboMagic

[Codehunter]

Nimm doch mal GetMem statt New. Da kannst du die Größe explizit angeben.

[TurboMagic]

Zitat:

Zitat von Codehunter (Beitrag 1435381)

Nimm doch mal GetMem statt New. Da kannst du die Größe explizit angeben.

Danke für den Tipp, haben wir aber auch schon durch.
Die Frage ist gerade eher, warum die selbe Datenstruktur im einen Projekt 12 Byte schluckt und
im realen Projekt, ohne dass man im Code etwas anders macht, mehr als 1 KB schluckt.

Mich würde interessieren, wohin Peter's Spur führt und was man da tun könnte.
Wer verstellt diese Speichermanager Eigenschaften?

Das richtige Projekt benutzt außer Delphi's RTL/VCL auch noch JVCL Komponenten und das VST,
aber die sollten doch auch nicht den Speichermanager verstellen?!

[Neutral General]

Hab grad mal geschaut.
New ist am Ende in der .exe auch einfach nur ein GetMem. Das sollte also keinen Unterschied machen (außer Delphi glaubt in deinem Projekt, aus welchem Grund auch immer, dass dein Record 4KB groß ist). Falls das beim Debuggen auch auftritt kannst du aber theoretisch mal auf das new einen Breakpoint machen und dir das ganze im CPU-Fenster anschauen.

Delphi-Quellcode:

var testByteArr: PByteArray;
begin
  New(testByteArr);

CPU-Fenster:

Code:

Unit3.pas.156: New(testByteArr);
0064E055 B800040000       mov eax,$00000400 <---
0064E05A E81D8EDBFF        call @GetMem
0064E05F 8945E4           mov [ebp-$1c],eax

Da kannst du leicht erkennen wie viel Speicher er für dein Record tatsächlich reserviert.

[Codehunter]

Es gibt ja noch tausend weitere Möglichkeiten. Zum Beispiel ein record helper mit Inline-Methoden, der in einer Unit liegt die nur von einem Projekt eingebunden wird. Denn soweit ich die Eingangsfrage bei der Hitze verstehe, geht es ja nicht um das Ergebnis eines SizeOf() sondern um den Speicherverbrauch des ganzen Prozesses.

[Sherlock]

Mir ist klar, folgendes wird als Rat in der Regel abgelehnt, also bitte nicht böse werden, ist ja auch nur ein Testballon:
Ich würde das jetzt mal ganz pragmatisch sehen: Weiter Zeit vergeuden mit dem Versuch alten Code zu verwenden, oder einfach auf eine Klasse umsatteln? Zeiger sind so... 80er Jahre.

Sherlock

[Codehunter]

Zitat:

Zitat von Sherlock (Beitrag 1435398)

Mir ist klar, folgendes wird als Rat in der Regel abgelehnt, also bitte nicht böse werden, ist ja auch nur ein Testballon:
Ich würde das jetzt mal ganz pragmatisch sehen: Weiter Zeit vergeuden mit dem Versuch alten Code zu verwenden, oder einfach auf eine Klasse umsatteln? Zeiger sind so... 80er Jahre.

So ganz Unrecht hast du damit nicht. Man denkt gemeinhin, es gäbe gewaltige Performanceunterschiede. Tatsächlich aber sind Klassen (und generische Listen) unter bestimmten Szenarien sogar weitaus leistungsfähiger. Ich hatte einen Fall, wo ich bei Schleifen über Oldschool-Record-Listen eine Laufzeit von 60 Sekunden hatte und nach dem Umbau auf Klassen und TDictionary<key, myobject> eine Laufzeit von 4,5 Sekunden.

Und jedem Byte Speicherverbrauch nachzujagen ist auch vergeudete Müh. RAM ist das billigste und am einfachsten zu erweiternde Glied in der ganzen Problemkette.

[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:

Zitat von TurboMagic (Beitrag 1435404)

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.

[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:

Zitat von bcvs (Beitrag 1435427)

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:

Zitat von hoika (Beitrag 1435440)

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.

[TurboMagic]

Guten Morgen,

wir haben das Projekt mal auf meinen PC kopiert und da ausgeführt.
Wenn wir hier in New reinsteppen, läuft es den selben Pfad wie auf dem anderen PC, nur beim LEA
Aufruf bekomme ich hier eine Zugriffsverletzung angezeigt!

---------------------------
Benachrichtigung über Debugger-Problem
---------------------------
In Projekt D:\Projekte\Meins\Debug\Win32\Projekt.exe trat ein Problem mit folgender Meldung auf: 'access violation at 0x720d0ffa: read of address 0x720d0ffa'. Prozess angehalten. Mit Einzelne Anweisung oder Start fortsetzen.
---------------------------
OK
---------------------------

Interessant ist jedoch, dass wir diese Zugriffsverletzung nicht bekommen, wenn wir über den New Aufruf einfach drüber steppen, statt reinzusteppen! Komisch...

Grüße
TurboMagic

[Stevie]

Entweder ein schief gelaufener Codehook/Runtime patch (ist Assembler Code, der ausgeführt wird auch derselbe, der im Code steht?) oder eine Stack Corruption durch irgendwelchen anderen defekten Code? :glaskugel:

[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.
Siehe screenshots.

Was passiert hier?
Was haben wir irgendwo während des Programmumbaus vermurkst, das uns den Speicher irgendwie ruiniert?

[TurboMagic]

Nächster Versuch: wir haben jetzt FastMM4 Vollversion eingebunden und in der Include Datei CheckHeapForCorruption eingeschaltet.
Statt des normalen GetMem Aufrufes wird dann DebugGetMem aufgerufen, Size ist 10 aber sobald ich in diese Prozedur reinsteppen will,
springt er zurück! Schaue ich mir wenn ich direkt auf dem Aufruf stehe die Disassembly ANsicht an, so sehe ich da einen JMP.

Aber wieso?

[peterbelow]

Zitat:

Zitat von TurboMagic (Beitrag 1435422)

@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 :wink:, 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 :(.

[peterbelow]

Zitat:

Zitat von TurboMagic (Beitrag 1435454)

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.
Siehe screenshots.

Was passiert hier?
Was haben wir irgendwo während des Programmumbaus vermurkst, das uns den Speicher irgendwie ruiniert?

Wenn ihr den exakt gleichen Sourcecode auf zwei verschiedenen Rechnern kompiliert und dann solche Unterschiede im erzeugten Binärkode findet würde ich mal den Problemrechner sehr gründlich auf Malware prüfen. Vergleicht auch, was auf beiden Rechnern in der IDE als add-ons und sonstigen 3rd-party packages installiert ist.

Da die Diskrepanz in einem Kode-Segment auftritt kann es eigentlich kein einfacher memory overwrite zur Laufzeit sein, da Kode-Segmente ja dort read-only sind und daher ein Schreibversuch zu einer access violation führen müßte. Die Änderung muss also schon beim Kompilieren oder Linken der Anwendung erfolgen, aber halt nur auf deinem Rechner, nicht dem deines Kollegen. An den precompilierten dcus der RTL kann es nicht liegen, sonst würde der Fehler auch in deinem Testprogramm auftreten.

[Stevie]

Zitat:

Zitat von peterbelow (Beitrag 1435463)

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:

Zitat von TurboMagic (Beitrag 1435454)

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.