Unerklärlicher Speicherfresser

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

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

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