From: Admin of The Keep (
Date: 10/31/96

On Thu, 31 Oct 1996, The Chuckster wrote:

> Can anyone give me a brief walk thru on how to use GDB
> to find this problem? Someone mentioned start circle with
> GDB and then when the mud 'locks up' hit CTRL C in the
> GDB window and it will tell you what line the debugger is
> on.. This did not work.
> Any help is greatly appreciated, for I have stepped into
> uncharted lands with this debugger.

  gdb is cake, really.  I never use it to examine processes that are
  running, so I'm not learned in that area, but with core dumps I am
  familar with (unfortunately)...

  You'll have a core dump (depending on your OS) in 'lib' by the name
  of 'core' or 'circle.core' or something along those lines.  To use
  gdb to examine it type 'gdb bin/circle lib/core' replacing the first
  argument with the path and name of the circlemud binary that crashed
  and the second argument with the name of your core dump.

  gdb will show you the last place it was in when it crashed.  This is
  often times unuseful by itself as it will sometimes show a routine
  was passed invalid data (eg., a null) but knowing a null pointer had
  caused the crash and eliminating it is something entirely different.

  Some commands will help you figure out what happened and pretty much
  why.  A 'backtrace' (bt) will show the last few steps it took leading
  up to the crash.  The first one listed is where the actual MUD crashed.
  The 'list' command can be used to list line numbers (w/ context) or
  functions.  You cannot list a function in a specific file, gdb does not
  distinguish between files, so 'list do_say' will list the beginnings of
  the do_say function (presumably) and 'list 320' will list line 320 of
  whatever the current file is (where the function you crashed in is or
  where the function you last referenced is).  Typing 'list' without any
  arguments will continue listing (after you type it once though, it
  appears just pressing ENTER has the same effect).  The other command I
  found occassionally useful was 'print' which permits printing of some
  variables that are cast in the current function.  I don't know it's
  specifics and I only used it once.

  I don't think I've ever used gdb to track down an infinite loop, before.
  Or actually, I know I have, but I'm not sure what I did exactly.  The
  above may or may not help.

  "Forgive me father, for I am sin."

| Ensure that you have read the CircleMUD Mailing List FAQ: |
|   |

This archive was generated by hypermail 2b30 : 12/18/00 PST