Re: Segmentation Fault

From: Jason Huang (
Date: 10/05/95

On Wed, 4 Oct 1995, Daniel Koepke wrote:

> On Wed, 4 Oct 1995, Entreri wrote:
> > Hello,
> > 	Is there any easy way to check for the cause of a segmentation 
> > fault?  I am getting an annoying seg fault seemingly randomly.  What can
> > I do to find out the cause?
> > 
> >
> > Realms of Syldain < 4000>
> > 
> Segmentation faults, which are done by the UNIX, should core dump unless 
> the UNIX is told not to core dump (I suspect this is done via the 'limit' 
> command in bash, which I know allows you to change the max size of 
> cores), these can be checked with gdb ('info' should have information on 
> gdb).
> However, this is all rather unuseful for you, since netcom doesn't make 
> core dumps, and, although I'm uncertain, I doubt you're permitted to play 
> with 'limit'.  In any case, find a real site and then you'll have a much 
> easier time, until then, you'll need to crash the MUD purposely to find 
> out what code is causing the crash and then painstakingly comb over it to 
> find the bugs - often times it's a simple mistake, and many other times 
> it's like trying to find a needle in a haystack.
> Daniel Koepke (

Whenever Unix C tries to execute a program it cannot handle, it dumps 
whatever data it failed to handle from memory into a file, commonly 
called core dump; and, usually, as a consequence of segmentation fault, 
bus error, memory fault, and pipeline error ( just naming some that has 
happened to me ). You can decipher whatever went wrong with the help of a 
debugger such as gdb.

Although I am currently working with envy, my suggestion is general and 
applies to you. Just type gdb circle (circle being your execuable file), 
fol by core 1011.core, where 1011.core is an example of a core dump you 
might get on netcom. It should then tell you at what line in your program 
UNIX gave up.

Note that the core dump is the *effect* of the problems in your coding, 
not the source. So frequently, you will spend additional time tracking 
down the real problem, usually not the one reported in the core dump. 
There is a hacker.txt from merc documents ( I believe it is included in 
circle as well) that might help you somewhat.

As far as the allegation of no core-dumps on netcom, it is completely 
false. I should know --- I am coding spells on my account and have my 
share of core-dumps. You might want to check your shell script (.cshrc) 
to make sure you have no limit coredumpsize 0. There is some motivation 
for adding limit coredumpsize, namely the disk space quota --- more disk 
space usage, higher account charge. So, I suggest you run the mud from 
usr/hack/tmp directory.

Running your mud on nectom is fine for developmental purposes or if you 
have a small player-base. Netcome is noticeably sluggish at peak time and 
you will hear complains from your players about the lag once your mud 
expands. And then, it is time for a better site.

Jason Huang

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