Re: Memory Wrapper

From: Sammy (samedi@DHC.NET)
Date: 05/21/98

On Tue, 19 May 1998, George wrote:

> I did that with my Buffer System, it has a little flag in buffer.h for a
> 'BUFFER_MEMORY' flag you can turn on.  It gets really slow when you do
> that, but it does track all memory and report overruns.  The only real
> problem with it is that currently (on x86), it allocates a 28 byte
> structure for tracking, even if you do a 1 byte allocation. :)  I'll
> probably separate the buffer/memory structures so that there is less
> overhead in the future and my hash table should improve the speed. (On cue
> for v1.8)

The structure I use looks to be about 16 bytes at the moment.  A hash
table is a very good idea.  Do you hash by address?

> It does magic number checking currently, when released.  It does a report,
> although the report by type would be nice.  Unfortunately, it would be far
> too much to list for all of the malloc() allocations.

I was thinking I'll probably start out by changing the CREATE macro to
call my new allocation function with the MEM_UNKOWN type.  Then I can
add CREATE_CHAR macros and make changes a few at a time.  It may be worth
it just to have the check for bad free() calls and periodic magic number
checks.  It'd also be nice to be able to write new code with a unique
MEM_TYPE to make check for memory problems while the code is still fresh.

I think I'll be adding a check_sanity() function that will check for
overruns or invalid pointers on demand for a single pointer.

> Not totally necessary.  If something is allocated in 'parse_object', well,
> you know what it is. :)

Is there a portable way to know the current function?

I'm probably going to try throwing this together and installing it in
stock pl12 to get an idea of how it'll work out.  I don't think I'd want
to use this fulltime, but I think it would be very useful as a
compile-time debugging option, and would be great to use on new code for a
month or two after writing it.

If you put a lock bit on the structure (maybe a negative memblock->type)
it might also be useful as a quick and dirty way of making data thread
safe, although the supporting code would be a lot of work.


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

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