On Wed, 3 Dec 1997, Chris Jacobson wrote:
> Im looking for a library that provides me with memory function debugging
> ability... but not 'dbmalloc'. What I really need is something that lets
> me backtrace from free(). I have random, unpredictable,
> non-reproduceable crashes in free(). They can be very rare, and happen
> anywhere from 2 minutes to 2 days after the MUD has been running.
> Usually within a couple hours tho. backtrace shows nothing beyond free().
Well, I tried out the following libraries, for debugging malloc stuff:
dbmalloc : Very slow, but detect errors, not very informative
ccmalloc : Sucks *grin*
lefence : Electric Fence... Fast, doesn't detect a lot except
memory underwrites in my oppinion. Does probly also
detect overwrites, but wasn't the problems I found
with it. It uses a SH*Tload of memory though.
checker : Some gcc clone, that should do some debugging also, but
it didn't compile very good, and it didn't compile the
mud code I use either, and I didn't feel like starting
to modify a GCC thingie.. (v2.7.2 btw).
I have to admit, that Georges suggested way of tracking debugging errors
wasn't all that bad *grin* If you make a free() call and move it arround
in the code, and free whatever is causing you the error, and find the spot
where it changes from OK to segfault, then you've got a pretty good chance
of fixing the error, and it's a lot faster than using those cursed
debugging libraries, that often don't pinpoint the type of bug causing the
crash in the malloc routines.
You could even do the following. Download the memory.c code I put online
somewhere, look for my old post *g* And hack this up, so when the my_free
is called it copies the file, function and line from where free() is
called from, and then running a debugger, you'll be able to examine what
free() call caused the malloc routines to go fruity on you.
This is actually a worthwhile idea to imp, thinking of it, since that
would show where some of the more suspecious malloc errors are causes,
ecept for the fact, that this would use some CPU time storing the file,
function and line number free was called from every time it's called.
Think the memory.c stuff is at:
http://palisades.dit.cbs.dk/memory.c
Can't test it now, since I'm having like 95% packet loss to the mashine
*sigh* Not to mention almost as bad packet loss to the outside world.
Regards,
Rand
.d
--
Rasmus Ronlev DOEK'94 http://www.econ.cbs.dk/~raro94ab
IT-Advisor mailto:raro94ab@student.econ.cbs.dk
B.Sc. Computer Science and Business Administration
Stud. M.Sc. Computer Science and Business Administration
+------------------------------------------------------------+
| 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