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

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

On Sat, 25 Jan 1997, Sammy wrote:

> Ever since I started learning to use the step command, there hasn't been a
> bug, crashbug or otherwise, that I haven't been able to track down with
> gdb.  It's really cut down on my debugging time.  Instead of the normal
> 10% coding, 90% debugging, it's more like 50-50 now :)

True, the 'step' command is quite useful (except when it steps into
a function you know isn't the problem :)), and does greaten the
possibility of tracking down the bug, but it's still not foolproof.
Step still wouldn't help with a memory problem, it'd simply crash at
some odd line that isn't faulty.

> I only wish I could explain my techniques better, but I can't stress
> enough how useful break, print, and step are if you only learn those three
> commands.

Simple enough.  Run the MUD in gdb using 'run', set a break point at
wherever it's crashing (or, like I do, a place prior to that, so that
I can check preceeding code for problems and 'step' into the crash) with
the 'break' command, make it hit the breakpoint and 'step' forward line
by line.  When you encounter a variable you suspect might be a problem,
use the 'print' command to see it's contents.

I wasn't saying that gdb wasn't strong enough to track down bugs, even
the tougher ones, and the 'break'/'step' (and 'disable break') commands
really aid in it.  I certainly wasn't suggesting everyone stop using
gdb, but I was saying is that you shouldn't take what it says as the
absolute truth.  No matter what method you use for debugging, you are
going to find nothing signifigantly helpful from gdb in the way of
memory problems.

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