Unerklärlicher Speicherfresser

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