[DUG] FastMM4 error reporting

[Phil Middlemiss]

Ah, now it makes sense. I thought it was trying to tell me that the 
actual creation of the object was causing the memory leak!

Now to the hunt!

Rohit Gupta wrote:
> These memory blocks have not been freed by the application when 
> it ended.  In most cases they will be freed by Windows.  If however 
> your program is running for a length of time, then it could be cause 
> for concern as the memory used may keep increasing.
>
> Date sent:	Thu, 26 Jan 2006 09:50:18 +1300
> From:	Phil Middlemiss <phil at tumonz.co.nz>
> Organization:	MTS Ltd
> To:	NZ Borland Developers Group - Delphi List <delphi at ns3.123.co.nz>
> Subject:	[DUG] FastMM4 error reporting
> Send reply to:	NZ Borland Developers Group - Delphi List <delphi at ns3.123.co.nz>
> 	<mailto:delphi-request at ns3.123.co.nz?subject=unsubscribe>
> 	<mailto:delphi-request at ns3.123.co.nz?subject=subscribe>
>
> I've just switched over to using FastMM4 in a Delphi 6 project and I'm 
> getting a rather HUGE list of errors logged to a file when the program 
> ends (which is fine). But I can't get my head around what the messages 
> are telling me. There are a lot of this kind of message:
>
> --------------------------------2006/1/26 
> 9:27:52--------------------------------
> A memory block has been leaked. The size is: 20
>
> Stack trace of when this block was allocated (return addresses):
> 402A47 [System][@GetMem]
> 403C37 [System][TObject.NewInstance]
> 403FFE [System][@ClassCreate]
> 403C6C [System][TObject.Create]
> 403FFE [System][@ClassCreate]
> 4C7A6A 
> [ClientLayerManager.pas][ClientLayerManager][TTZWebServiceScheme.Create][769]
> 4C6FC1 
> [ClientLayerManager.pas][ClientLayerManager][TTZWebServiceBlender.Create][543]
> 4C6A6C 
> [ClientLayerManager.pas][ClientLayerManager][TTZClientLayerManager.Initialise][369]
> 77F88DD6 [RtlDosSearchPath_U]
>
> The block is currently used for an object of class: TMemoryStream
>
> Current memory dump of 256 bytes starting at pointer address 1D76EA0:
> 70 04 42 00 60 43 2A 02 23 2A 00 00 00 00 00 00 00 40 00 00 C0 91 28 FE 
> 00 00 00 00 20 6E D7 01
> 00 00 00 00 00 00 00 00 FF FF FF FF 47 2A 40 00 37 3C 40 00 FE 3F 40 00 
> 4A 7A 4C 00 0F 79 4C 00
> C1 6F 4C 00 6C 6A 4C 00 D6 8D F8 77 AB 92 4C 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 14 00 00 00 
> 00 00 00 00 BF 6E D7 01
> F8 5F 4C 00 58 D0 D9 01 C0 37 AF A6 F5 E1 E2 40 A0 6F D7 01 40 91 28 FE 
> 00 00 00 00 20 6E D7 01
> 00 00 00 00 00 00 00 00 FF FF FF FF 47 2A 40 00 37 3C 40 00 FE 3F 40 00 
> 6C 3C 40 00 FE 3F 40 00
> 6A 7A 4C 00 C1 6F 4C 00 6C 6A 4C 00 D6 8D F8 77 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 14 00 00 00 
> 00 00 00 00 3F 6F D7 01
> p . B . ` C * . # * . . . . . . . @ . . À ` ( þ . . . . n × .
> . . . . . . . . ÿ ÿ ÿ ÿ G * @ . 7 < @ . þ ? @ . J z L . . y L .
> Á o L . l j L . Ö  ø w « ´ L . . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¿ n × .
> ø _ L . X Ð Ù . À 7 ¯ ¦ õ á â @ o × . @ ` ( þ . . . . n × .
> . . . . . . . . ÿ ÿ ÿ ÿ G * @ . 7 < @ . þ ? @ . l < @ . þ ? @ .
> j z L . Á o L . l j L . Ö  ø w . . . . . . . . . . . . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . ? o × .
>
> --------------------------------2006/1/26 
> 9:27:52--------------------------------
>
> But I don't understand why this would be happening? It's just a simple 
> construction chain with parent objects creating child objects in their 
> constructors. There's no tricky pointer operations going on or anything 
> strange - just a bunch of objects being created. It appears from the 
> stack dump that it's the Memory Manager that has the problem - can 
> anyone shed any light here?
>
> Phil.
> Regards
>
> Rohit
>
> ======================================================================
> CFL - Computer Fanatics Ltd.  21 Barry's Point Road, AKL, New Zealand
> PH    (649) 489-2280 
> FX    (649) 489-2290
> email rohit at cfl.co.nz  or  r.gupta at xtra.co.nz
> ======================================================================
>
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phil.vcf
Type: text/x-vcard
Size: 250 bytes
Desc: not available
Url : http://ns3.123.co.nz/pipermail/delphi/attachments/20060126/1ad36847/phil.vcf