Re: Does dropping objects really free memory?

[Paul E. Johnson]

"Marcus G. Daniels" wrote:
> 
> >>>>> "FM" == famasce  <address@hidden> writes:
> 
> FM> The link to dmalloc are broken.
> 
> The current URL is: http://www.dmalloc.com
> 
> Note that since most allocation will be done via Zones, even if
> you build Swarm and your model including dmalloc.h you won't get
> direct information about where leaks occur -- it will just report Zone.m.
> 
> However, the section "Tracking down Non-Freed memory" describes how
> you can use the STORE_SEEN_COUNT option in dmalloc to associate
> pointers with stack traces in gdb.
> 
I've spent the day with docs you mention and I've asked in the dmalloc
group for a little more information about how it is supposed to work.  

I have a Swarm followup, however, and I bet the dmalloc guys will want
me to answer this.

Suppose I have allocBlock: calls in my code for dynamic allocation of
arrays in swarm.  Suppose I quit my swarm program and those objects have
not yet been told to free their allocation.  Are those "unfreed blocks"
going to show in dmalloc's output just the same as blocks that are lost
due to a memory leak, say something that results from dropping an object
before calling the code to free the memory that it grabs with
allocBlock:?

Am I making any sense to you?

If I see 10,000 lines in the output with references to Zone.m like
below, how do I know which ones are bad leaks and which are the ones
that naturally exist when the program ends before some of its objects
get killed?

940349216: 302075: not freed: '0x8582188|s679' (32 bytes) from
'Zone.m:33'
940349216: 302075: not freed: '0x85821c8|s1' (32 bytes) from 'Zone.m:33'
940349216: 302075: not freed: '0x8582208|s1' (32 bytes) from 'Zone.m:33'
940349216: 302075: not freed: '0x8582248|s167' (32 bytes) from
'ra=0x4036ecb7'
940349216: 302075: not freed: '0x8582288|s1279' (32 bytes) from
'ra=0x4036ecb7'
940349216: 302075: not freed: '0x85822c8|s11' (32 bytes) from
'Zone.m:33'
940349216: 302075: not freed: '0x8582308|s85' (32 bytes) from
'Zone.m:33'

One thing I've done to try to pinpoint the leaks in my code is I've put
the xmalloc calls back in place of allocBlock:. Dmalloc recognizes those
and complains about my files, not Zone.m.  

-- 
Paul E. Johnson                         email: address@hidden
Dept. of Political Science              http://lark.cc.ukans.edu/~pauljohn
University of Kansas                    Office: (785) 864-9086
Lawrence, Kansas 66045                  FAX: (785) 864-5700

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.