Re: [CODE] Freeze error, GDB and .c output, please help.:)

From: Daniel Koepke (
Date: 01/24/97

On Fri, 24 Jan 1997, Eduardo Gutierrez de Oliveira wrote:

> As soon as a user logs in I get a gethostbyaddr error (no such file or
> directory), which I cannot even begin to deduct what could it be pointing
> to. Only outer users give this error.

Most likely, this is coincidence, and not involved with this.

> I don't know what else to post, I am not sure if I should post further
> examples of the thing (you tell me which), I need a direction here, since
> I am just doing my first attempts at using gdb...

My mount patch, to my knowledge, only has 2 or 3 small little "glitches",
and no crash or infinite loop bugs.  And it's not related to line 1024,
that's a standard act() statement and wouldn't cause an infinite loop
unless you changed the code.

Here's my suggestion, when the MUD freezes, exit telnet (use the escape
character then type 'close' at the telnet> prompt), get the pid of the
bin/circle process and kill it using SIGSEGV (signal 11).  On my system
this is accomplished like "kill -s 11 <pid>".  This will cause the MUD
to crash and coredump while still inside the infinite loop.

Please take notice that bugs can be quite tricky to track down, even when
using gdb.  While gdb definitely will help you, there's many times when
it's not much good (especially memory problems).  On many occassions gdb
will help you locate many stupid crash/infinite loop bugs.  There are
many things you can in and out of gdb to help you track down faulty code.
For one, the 'print' command in gdb is useful when you want to check the
values of variables.  This really helped me yesterday, when I was adding
a warm boot mode to the MUD I'm coding from the ground up (eg., players
aren't logged off over the reboot).  I accidentally added the socket_data
entry for the player twice into the Connections linked list, which caused
an infinite loop.  Intelligent use of the 'print' command (eg., checking
what the head of the list was, then what the next element was and
comparing the addresses gdb gives as the values) helped me determine where
the problem was.  Examining the actual code helped me find the faulty
code and fix it.  It was a stupid error, but a pain in the ass since I
went running in circles looking for why it was adding the player into the
connections list more than once.  Duh.

My point is, that 'gdb' can be quite a useful tool, but most of the time
it will only point you in the general direction, and other times it will
do absolutely nothing for you, and still other times it will give you the
answer right out.  It is a coder's best friend, true, but it's not the
most reliable of friends.  Take what it gives you for what it's worth, and
not as the absolute truth.

Daniel Koepke
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