Re: Memory Allocation Tracking

From: Mark A. Heilpern (heilpern@MINDSPRING.COM)
Date: 01/08/98

At 09:29 PM 1/7/98 -0900, you wrote:
>#define FREE(item) { statistics.mem_alloc-=sizeof(item); free(item); }
>As you will no doubt see, the free call is not returning the
>correct amount of memory that will be freed.
>It seems that the sizeof(item) call is incorrect for the purpose.
>My question:
>1) What is the correct method of determining the amount of memory
>a particular data structure is using? I don't want to write a routine
>to handle every darn struct in the mud and all the possiblities. I'd
>rather spend my time creating a new feature or finishing a skill.

For a structure, sizeof(type) is fine. However, sizeof() will not help you on
freeing buffers that were not allocated for a structure. For example, when
str_dup() allocates, it allocates based on the strlen() of the incoming
The bottom line - unless you want to learn how free() determines how much
memory it will return to the malloc pool (that is, learn malloc structure
you can't do what you you want without keeping your own tables of every
allocated and the size at that location.

>2) If #1 isn't feasible, a long stored in each struct could handle the
>memory allocated for the purposes of tracking, but that seems rather
>odd, and less than 100% reliable, not to mention wasting 4 bytes for
>every memory allocation.

Again, how will you handle strings?

>3) I could create a struct to hold pointers to all the stuff that's
>allocated and the amount of memory in that allocation. But that'd be
>slow when it comes time to add/remove from the list.

Not to mention this is already done in some fasion or another by malloc.

If I were to pursue this, to do it in a portable manner, I'd create a
linked list
of every allocation/size, add to this list of every CREATE, remove from the
list on every FREE, and both remove and add on RECREATE. However,
because I'd rather not spend the cpu bandwidth/additional memory resources...

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST