AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

MemoryLeak mit madExcept

Ein Thema von sakura · begonnen am 21. Nov 2016 · letzter Beitrag vom 21. Nov 2016
Antwort Antwort
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: Unterhaching
11.412 Beiträge
 
Delphi 12 Athens
 
#1

MemoryLeak mit madExcept

  Alt 21. Nov 2016, 11:15
Hallo,

hier mal etwas Kniffeliges, ich habe eine kleine Anwendung und mehrere DLLs, welche zur Laufzeit geladen werden.

Alle DLLs (3 Stück) und die Anwendung nutzen den FastMM 4.991 (FullDebugMode ist eingeschaltet), und madExcept 4.0.16.

Wenn ich madExcept überall ausschalte, dann läuft die Anwendung ohne jegliche Speicherlöcher.
Wenn ich madExcept überall einschalte, dann läuft die Anwendung problemfrei, beim Beenden meldet FastMM jedoch ein Speicherlöchlein...

P.S.: Es reicht auch, madExcept in der EXE auszuschalten, damit es keine Speicherlöcher mehr gibt...

Code:
--------------------------------2016/11/21 11:11:55--------------------------------
A memory block has been leaked. The size is: 12

This block was allocated by thread 0xA0C, and the stack trace (return addresses) at the time was:
40710A [System.pas][System][@GetMem$qqri][4614]
4AC04F [madExcept][HandleCreateThreadHook$qqripvt2rp21Madexcept.TThreadInfor20System.UnicodeStringrpv]
77668C59 [RtlSetLastWin32Error]
4D586DE [FastMM4.pas][FastMM4][SumNativeUInts$qqruipuiui][8166]
4D586ED [FastMM4.pas][FastMM4][CheckFillPattern$qqrpvuiui][8192]
4D59968 [FastMM4.pas][FastMM4][DebugReallocMem$qqrpvi][8980]
4D5997A [FastMM4.pas][FastMM4][DebugReallocMem$qqrpvi][8987]
776AE7BC [ZwCreateNamedPipeFile]
7666AA3A [CreatePipe]
4AC26A [madExcept][HookedCreateRemoteThreadEx$qqsuipvuit2t2uit2rui]
4DDF406 [madExcept][HandleExceptionThread$qqspv]

The block is currently used for an object of class: Unknown

The allocation number is: 4189

Current memory dump of 256 bytes starting at pointer address 7FE78C20:
5C F3 DD 04 00 00 00 00 A8 39 C5 0F 80 80 80 80 00 00 00 00 61 90 E7 7F 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 B4 10 00 00 79 71 40 00 77 D0 40 00 C6 D1 40 00 6F 88 6D 00 96 86 41 00
84 9E 41 00 26 71 40 00 4F 74 6D 00 B7 84 6D 00 8D 73 6D 00 EC 91 40 00 0C 0A 00 00 0C 0A 00 00
26 71 40 00 20 D3 40 00 26 8A 6D 00 4F 74 6D 00 B7 84 6D 00 8D 73 6D 00 EC 91 40 00 5B 84 6D 00
4E FE 40 00 3D C0 65 00 9B E0 54 08 0C 00 00 00 00 00 00 00 60 D2 44 8F E4 EB 70 00 80 80 80 80
80 80 80 80 9F 2D BB 70 00 00 00 00 69 8D E7 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC 14 00 00 0A 71 40 00 1B 89 40 00 42 91 40 00 8C 8A 40 00 2F 47 6D 00 6A 82 6D 00 AE FA 6C 00
BA FD 6E 00 7D 1E 5A 00 8B C0 5B 00 F1 CB 5B 00 0C 0A 00 00 0C 0A 00 00 26 71 40 00 39 89 40 00
\  ó  Ý  . . . . . ¨  9  Å  . € € € € . . . . a   ç    . . . . . . . .
. . . . . . . . ´  . . . y q @  . w Р @  . Æ  Ñ  @  . o ˆ m . – † A .
„ ž A . & q @  . O t m . ·  „ m .   s m . ì  ‘ @  . . . . . . . . .
& q @  .    Ó  @  . & Š m . O t m . ·  „ m .   s m . ì  ‘ @  . [  „ m .
N þ  @  . = À  e . › à  T . . . . . . . . . `  Ò  D   ä  ë  p . € € € €
€ € € € Ÿ -  »  p . . . . i   ç    . . . . . . . . . . . . . . . .
ü  . . . . q @  . . ‰ @  . B ‘ @  . Œ Š @  . /  G m . j ‚ m . ®  ú  l .
º  ý  n . }  . Z . ‹ À  [  . ñ  Ë  [  . . . . . . . . . & q @  . 9  ‰ @  .

--------------------------------2016/11/21 11:11:55--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

5 - 12 bytes: Unknown x 1
Wer kennt das Problem, oder hat eventuell eine Idee?

......
Daniel Lizbeth
Ich bin nicht zurück, ich tue nur so

Geändert von sakura (21. Nov 2016 um 11:21 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

AW: MemoryLeak mit madExcept

  Alt 21. Nov 2016, 17:55
Schaut aus, als ob in madExcept.HandleCreateThreadHook was nicht wieder freigegeben wird. Da im Callstack keine Zeilennummer steht (nimm evtl mal debugsymbole für die unit rein und lass sie neu kompilieren - einfach die madExcept.pas explizit dafür ins Projekt aufnehmen, sonst nutzt er die dcu von der madCollection Installation).

Ich würd ja raten, dass es der Speicher vom VirtualAlloc ist (SizeOf(tti^) sollten 12 Byte sein), allerdings fügt PatchPtr weiter unten das in eine Liste ein, die im FreePatches, was im finalization aufgerufen wird, wieder freigegeben wird durch VirtualFree. Eventuell dort mal durch debuggen, obs da irgendwo hakt.

Edit: Nachdem ich Primož Gabrijelčič gefragt habe, kann ich sagen, dass es nicht das VirtualAlloc ist, das wird von FastMM nicht gehooked und somit werden mögliche Leaks daraus nicht erkannt. Scheint also was anderes zu sein. Zusätzliche Debuginfo im madExcept könnte aber den Callstack etwas verbessern, um die Ursache möglicherweise zu finden.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (21. Nov 2016 um 17:59 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


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 10:29 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz