> There is some serios stuff ahead... this is not for the faint of heart.
>
> My memory problems continue, yet on rare occassions. I cannot find the
> overrun errors, or underrun, whichever it is (more likely overrun). I
> continue to get them, unreproduceably, and without a trace of whats
> happening/happened.
Would you mind giving all the details? Operating system, compiler, error
output, etc. How sure are you about what's causing the problem? Have you
found and fixed any bugs (ie- are we talking about multiple bugs or are
you still hunting after one elusive bug)? It sounds like your mud is
open to the public. Have you asked the players for information? Has your
mud been crashing around the same time of day/with the same players on?
> I also still get (also on rare occasions), problems with freeing memory,
> although this has not happened in the last 24 hours. I have a special
> function, "my_free" which sets two global variables - a char * and an int
> - to the func name and line # of the caller. This is simply using my
> FREE(a) macro that I replaced free() with in most of my code, which calls
> my_free(a, __FUNCTION__, __LINE__);
> However, what is odd is when it crashes, last_func (which points to the
> name of hte last my_free caller) is pointing to a valid addr, which is a
> NULL string. Also, last_line, which is set tot he line of the last
> my_free caller, is 0. This is extremely confusing - it shouldn't be
> happening as far as I know.
Do you have that char * point to __FUNCTION__ or do you have space
allocated and copy the value of __FUNCTION__ into it? I'm not sure,
but I wouldn't trust that simply keeping a pointer to __FUNCTION__
is safe.
Also, as you may know free doesn't null the pointers passed to it.
Since the only way to test for the validity of pointers is comparing
them to null I suggest, if you aren't already doing this, to have your
free() macro null all freed pointers (otherwise those "if (!ptr) do error"
lines in the code aren't going to do any good).
> So waht I need is a memor debugging tool, or advice, that will help. I
> have tried dbmalloc, but its too slow. Electric Fence was also too slow,
> and brought my memory usage up past 100 megs (normally under 10). If
> there is a commercial memory debugger that could help, I will even look
> into that.
Didn't Tom Daily offer to test anyone's code with his copy of Purify? I
don't have his e-mail address handy, but you should try to contact him.
This may sound silly but I've found an effective debugging technique to
be, of all things, simply reading the source code. It's kind of a
last-ditch-toss-the-ball-at-the-hoop-and-hope-it-goes-in type deal, but
a good cleaning never hurt any program. You'll probably find a couple
bugs that haven't become real problems yet. Think of it as preemptive
debugging. :)
I. Determine which parts to examine.
Start out with any code you've added recently. Think about what might be
going on in your mud that's different from a stock CircleMUD. Is OLC used
or do you have a seperate builder's port? Have you added any new immortal
commands that allocate/free memory? Have you messed with string parsing?
Do you use MobProgs? Do you put an unusual amount of stress on any particular
part of the mud? Huge areas, lots of creation and deletion, rooms that
collect an unusual number of mobiles/items, unusual special procs, etc.
II. Look for common logic errors.
Carefully scan the relevant pieces of code looking for the kind of logic
errors that tend to slip by. Check loops to make sure memory isn't being
read or written out of bounds. Check for strings that aren't null terminated.
Check for possible sign or size conversion problems. Check for attempts to
modify constant strings. Take each function and make sure it handles unexpected
values (and logs them when they occur so you know there's something wrong).
III. Look for "meta" errors.
Lapses in design happen all too frequently, especially when people program
straight from ideas in their head instead of putting them down on paper first.
(I'm guilty of that.) For instance, sometimes people will have pointers in
mulitple structures point to the same piece of memory, and then when they free
*one* of those structures they'll also free the shared memory. These kinds of
errors are the hardest to find. You'll need a good knowledge of what's going on
and a nice text editor/ide to jump around the source code. :)
IV. Call the Psychic Friends Network.
Okay, I'm joking.
Seriously, I don't know if any of this will help you. You may already know
everything I just told you, but that's what you get for posting your
problem without more details. :)
+------------------------------------------------------------+
| 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