MemoryLeak mit madExcept

[sakura]

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?

......

[Stevie]

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.