Re: unknown bug in my mud?

From: Peter Ajamian (peter@pajamian.dhs.org)
Date: 04/14/01


Kras Kresh wrote:
>
> Recently I've been experiencing some unknown bug that when the mud
> crashes i gdb the core file and i gives me the line of where the
> game crashed
>
> #0  0x206c6f74 in ?? ()

That means that the seg fault actually caused the core dump to get messed
up.  What it also means is that you're in for a hell of a time
troubleshooting the problem.  My recommendation is to first compile your
program with Electric Fence (efence) linked in and see if it provides any
more help (it may or may not help).  Don't post back and ask what's
efence, it's been discussed before so search the archives first, then
post back.  Note that if you're system does not have efence it _is_
possible to download the source from http://www.perens.com/FreeSoftware/
and compile and link it as non-root.

There are also other memory allocation debugging tools that may or may
not help.  If all else fails you will be stuck with getting into a real
dirty gdb session setting breakpoints and trying to find the line where
it crashes and get it to stop there _before_ it crashes.  Don't ask me
how to do this either, use the built-in help for gdb and other documents
available online to figure this out (it's a real pain and a last resort,
but it does work).

Some things that will help are:

Ask yourself what you changed between the last time you saw it working
and the first time you noticed that it didn't work, focus your
troubleshooting in these changed areas.

Revert back your last one or two changes (more if neccessary and able),
test to see if the problem is still there then apply changes back one at
a time.  Hopefully you have some method of reverting your changes back
(CVS is the easiest and best if you've been using it, otherwise old
backups, whatever you have available).  Worst case scenario try to
manually revert your changes back from memory (this is far from fool
proof but it might be the only solution you've got).

Try commenting out chunks of suspicious code (use #if 0/#endif not /* */
to do this as C does not work with recursive comments, but the #if
preprocessor stuff works recursively).

Ideas for the future:

Use some kind of revision control system.  I highly recommend CVS, but if
you don't want to put in the time and effort to set up something like CVS
the following while being rather rudimentary will work (though eventually
it will probably end up requiring just as much, if not more time and
effort than CVS)...

Create a new file in the src directory called revisions.h.  Whenever you
add new code put a #define in this filewhich describes what you're
adding, something like this...

#define DIAGONAL_DIRECTIONS_SNIPPET 1

Then in any file that you're changing for the new code add a #include
"revisions.h" and make your changes like this...

#ifdef DIAGONAL_DIRECTIONS_SNIPPET
/* New code goes in here */
#else
/* Old code that you're replacing goes in here (if you're just adding
code then leave out the #else part entirely) */
#endif

Then if you need to revert that change all you have to do is take out the
#define in revisions.h like this...

#if 0
#define DIAGONAL_DIRECTIONS_SNIPPET
#endif

Then re-compile.

If you ever want to add the code back in just change the 0 to a 1 on the
#if line.

Note that this rudimentary system is not entirely fool proof as it is
possible to accidentaly tweak parts of t he code that you're not aware of
and would not get covered by the #ifdef/#endif's that you're putting in.
You should still back up if you're gonna use this system.

Regards, Peter

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/05/01 PST