Re: CHECKPOINT shutdown

From: Daniel A. Koepke (
Date: 04/28/02

On Sun, 28 Apr 2002, Kras Kresh wrote:

> The dumps are absolutely useless if this happens. Running from the
> debugger won't help either.

Don't underestimate the debugger.  If you caught the Mud in the infinite
loop, attaching gdb to its process would stop it in the loop it's stuck
in.  The first thing we can suspect happening is that the data we're
looping over it somehow bad, so if the loop we're stuck in is

  for (wch = world[ch->in_room].people; wch; wch = wch->next_in_room) {

a good idea would be to do:

  (gdb) display wch

Now we want to walk through the loop:

  (gdb) n

and just keep hitting ENTER, watching 'wch' change as we go through the
loop.  Eventually, we find that some value (address) for wch repeats.  We
look at where a room's list of people is altered.  char_from_room() and
char_to_room() are likely points of access.

Restart the game inside the debugger.  Set a breakpoint on our
char_x_room() functions.  Now go about playing it, hitting all the new
features you've added since the bug appeared.  Whenever the Mud stops,
look at the backtrace, look at ch->in_room, and see what would happen.
If nothing bad, hit 'continue'.  Eventually, we'll run into a case where
ch->in_room isn't NOWHERE when we get into char_to_room().  Or we notice
that we get a char_to_room() call without a corresponding char_from_room()
call.  By looking at our backtrace, we see where the call came from, list
that functions code, notice that it does indeed do char_to_room() without
calling char_from_room(), and, voila, we know where our problem is.


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT