AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Unerklärlicher Speicherfresser

Ein Thema von TurboMagic · begonnen am 26. Jun 2019 · letzter Beitrag vom 27. Jun 2019
Antwort Antwort
Seite 3 von 4     123 4   
bcvs

Registriert seit: 16. Jun 2011
402 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#21

AW: Unerklärlicher Speicherfresser

  Alt 26. Jun 2019, 20:38
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.
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
393 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#22

AW: Unerklärlicher Speicherfresser

  Alt 26. Jun 2019, 22:03
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.
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
1.937 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#23

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 06:15
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
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
7.178 Beiträge
 
Delphi XE4 Professional
 
#24

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 06:20
Hallo,
das waren meines Wissens 800 MB ...
also doch schon etwas gefräßig.
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
1.937 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#25

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 07:10
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
393 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#26

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 09:18
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
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
3.543 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#27

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 09:22
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?
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
393 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#28

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 09:30
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?
Miniaturansicht angehängter Grafiken
pc_mit_av.jpg   pc_ohne_av.png  
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
393 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#29

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 09:42
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?
  Mit Zitat antworten Zitat
peterbelow

Registriert seit: 12. Jan 2019
Ort: Hessen
355 Beiträge
 
Delphi 10.3 Rio
 
#30

AW: Unerklärlicher Speicherfresser

  Alt 27. Jun 2019, 10:06
@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 .
Peter Below
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf