Ergebnis der Suchanfrage

• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 27. Jun 2019
  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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 27. Jun 2019
  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?
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 27. Jun 2019
  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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  Ä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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  @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.
  ...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  Eine weitere Erkenntnis:
  
  Der Aufruf von New springt nach GETMEM.INC und zwar in diese Routine:
  
  
  function SysGetMem(Size: NativeInt): Pointer;
  asm
  {$ifdef CPU386}
  {---------------32-bit BASM SysGetMem---------------}
  {On entry:
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  Nein, beides Debug Builds.
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  Das haben wir schon alles probiert, leider erfolglos.
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  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...
• Forum: Win32/Win64 API (native code)

  AW: Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  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
• Forum: Win32/Win64 API (native code)

  Unerklärlicher Speicherfresser

   
    by TurboMagic, 26. Jun 2019
  Hallo,
  
  ich schreibe gerade mittels Tokyo ein Programm, welches Zeiger auf einen Recordtyp anlegt.
  
  Beispiel:
  
  type
  TAuthorizationLevel = (alNone, alEverybody, al1, al2, al3);
  
  TMyRegister = record