Unerklärlicher Speicherfresser

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