Re: That "goto" problem

From: Alexander J Skrabut (
Date: 07/22/94

> So I ran a debugger on the MUD and noticed that we had an error of "bad 
> memory allocation" or something like that.  
> We figured it may have been a problem with the machine's memory not 
> reseting, so we rebooted the machine.  Ionic (out other Imp) got on the 
> MUD, and everything worked fine, so we assumed the bug was fixed...wrong.

It seems that you (and alot of coders out there) don't know how to use 
the debugger utility properly. Here are a few hints:

When you compile your mud, make sure you use the flag -g.
Make sure that you have limit coredumpsize 1000 in your .login or .cshrc.
When the mud crashes, it will dump memory into a file called 'core'. To 
examine this information, tybe dbx bin/circle (or however you have your 
directories set up). You'll get a bunch of cryptic information on the 
screen. Type where and hit return. On your screen will list the function 
that caused your program to die. It'll even show you the file name and 
line number! To exit dbx, type quit.

A memory violation or memory allocation error is not a result of your 
machine going haywire, Ace. What a memory allocation error is that the 
program tried to copy something into memory when the program hadn't made 
room in memory for it previously (usually).


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