On 12/3/97 9:08 PM, George (greerga@CIRCLEMUD.ORG) stated:
>If you can figure out what is scribbling over memory then you can figure
>out what is causing the crash. (I'd recommend picky buffers if you are
>using the buffer patch.) Otherwise, if you find a way to reproduce it, you
>can move free() statements around. mob_proto usually works well.
>Unfortunately, the buffer patch won't detect overruns in structures because
>it is only used for strings....ah well, maybe in the future. :)
>(Actually, it wouldn't be that hard.)
I have already wrote a NEW patch called "Memory Manager" totally based on
your Buffer patch, but only using two functions: circle_malloc and
circle_free. Actually the only reason I based it on your patch was it
did the same basic function ;-)
It uses about 16 bytes per ptr, which isn't bad, since it stores the
alloced size (why, I don't know... I guess for debugging purposes) and
for a ptr to the string const of the function, and the line #.
I'ld release it but I didn't comment it, nor do I have the time or
resources to make it a real patch, and it IS based on George's code. It
wasn't hard to do really, maybe 10 minutes.
I have however found an odd problem in that sometimes free_obj will be
called about 2,000 times in a row (seriously), trying to release string
ptrs that aren't in the list (but might have been at first) , and at
first it will report that it is freeing a unique obj many many times
(shouldn't really happen anyways). This is reported because I added a
log statement for when it does free a unique obj (unique meaning nr ==
-1, so it will release the strings too). As I said, shouldn't happen
except in freeing an unsaved new obj from OLC, which wouldn't hbappen
several times in the same second.
I don't think I would have been able to track this down without my memory
functions.
- Chris Jacobson
+------------------------------------------------------------+
| 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/08/00 PST