One of those objects is being created, but not free'd.

It gives you the file and line of the problem, so if you go there you will see 
whats being created, an not free'd.

When I started using FastMM I had a few of these, and most were obvious, 
however there was one that had me stumped for a while, but it turned out thet 
it was the top level object that wasn't being freed, not the bottom level 
object that it was complaining about.

Stacey

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rohit Gupta
Sent: Thursday, 26 January 2006 11:03 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] FastMM4 error reporting

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 <[EMAIL PROTECTED]>
Organization:   MTS Ltd
To:     NZ Borland Developers Group - Delphi List <[email protected]>
Subject:        [DUG] FastMM4 error reporting
Send reply to:  NZ Borland Developers Group - Delphi List <[email protected]>
        <mailto:[EMAIL PROTECTED]>
        <mailto:[EMAIL PROTECTED]>

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 [EMAIL PROTECTED]
403C37 [System][TObject.NewInstance]
403FFE [EMAIL PROTECTED]
403C6C [System][TObject.Create]
403FFE [EMAIL PROTECTED]
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 [EMAIL PROTECTED]  or  [EMAIL PROTECTED] 
======================================================================


_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi

Reply via email to