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.
Sam
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST